Fin de la trad de pgbench

postgresql/pgbench.xml

@@ -452,43 +452,42 @@ pgbench <optional> <replaceable>options</replaceable> </optional> <replaceable>n
       <term><option>--rate=</option><replaceable>taux</replaceable></term>
       <listitem>
        <para>
-        Execute transactions targeting the specified rate instead of running
-        as fast as possible (the default).  The rate is given in transactions
-        per second.  If the targeted rate is above the maximum possible rate,
-        the rate limit won't impact the results.
+        Exécuter les transactions en ciblant le taux indiqué plutôt que de les
+        exécuter le plus rapidement possible (comportement par défaut). Le taux
+        est donné en transactions par seconde. Si le taux cible est au-dessus
+        du taux maximal, la limite de taux n'impactera pas les résultats.
        </para>
        <para>
-        The rate is targeted by starting transactions along a
-        Poisson-distributed schedule time line.  The expected start time
-        schedule moves forward based on when the client first started, not
-        when the previous transaction ended.  That approach means that when
-        transactions go past their original scheduled end time, it is
-        possible for later ones to catch up again.
+        Le taux est ciblé en commençant les transactions en utilisant une ligne
+        de temps basée sur la distribution de Poisson. Le temps de démarrage
+        attendu se déplace suivant le premier client démarré, et non pas suivant
+        la fin de la transaction précédente. Cette approche signifie que, quand
+        les transactions dépassent leur durée finale prévue, les suivants
+        peuvent récupérer de nouveau.
        </para>
        <para>
-        When throttling is active, the average and maximum transaction
-        schedule lag time are reported in ms.  This is the delay between
-        the original scheduled transaction time and the actual transaction
-        start times.  The schedule lag shows whether a transaction was
-        started on time or late.  Once a client starts running behind its
-        schedule, every following transaction can continue to be penalized
-        for schedule lag.  If faster transactions are able to catch up, it's
-        possible for them to get back on schedule again.  The lag measurement
-        of every transaction is shown when pgbench is run with debugging
-        output.
+        Quand l'application du taux est actif, les durées de retard maximale et
+        moyenne sont rapportées en millisecondes. C'est le délai entre la durée
+        de transaction prévue et les heures de démarrage réelles des transactions.
+        Le retard montre si une transaction a commencé à temps ou en retard. Une
+        fois qu'un client a commencé son exécution en retard, chaque transaction
+        suivante peut continuer à être pénalisée pour un retard de planning. Si
+        des transactions plus rapides sont capables de rattraper le retard, il
+        leur est possible de revenir au planning prévu. La mesure du retard pour
+        chaque transaction est affichée quand pgbench est exécuté avec la sortie
+        de débuggage.
        </para>
        <para>
-        High rate limit schedule lag values, that is lag values that are large
-        compared to the actual transaction latency, indicate that something is
-        amiss in the throttling process.  High schedule lag can highlight a subtle
-        problem there even if the target rate limit is met in the end.  One
-        possible cause of schedule lag is insufficient pgbench threads to
-        handle all of the clients.  To improve that, consider reducing the
-        number of clients, increasing the number of threads in pgbench, or
-        running pgbench on a separate host.  Another possibility is that the
-        database is not keeping up with the load at some point.  When that
-        happens, you will have to reduce the expected transaction rate to
-        lower schedule lag.
+        Des valeurs de retard importantes par rapport au retard des transactions
+        actuelles indiquent que quelque chose ne va pas au processus de gestion
+        du taux. Un retard important peut surligner un problème subtile même si
+        le taux limite cible est finalement rencontré. Une cause possible de
+        retard est un nombre insuffisant de threads pgbench pour gérer tous les
+        clients. Pour améliorer cela, considérez réduire le nombre de clients,
+        augmenter le nombre de threads dans pgbench ou exécuter pgbench sur un
+        autre serveur. Une autre possibilité est que la base de données n'arrive
+        pas à supporter la charge. Quand cela arrive, vous aurez besoin de
+        réduire le taux de transactions attendu pour réduire le retard.
        </para>
       </listitem>
      </varlistentry>