Débit vs latence : comment ils interagissent sous charge

16 octobre 2026 8 min de lecture

Le débit (throughput) est la quantité de travail qu’un système termine par unité de temps, par exemple des requêtes par seconde. La latence est le temps que prend une unité de travail, par exemple 120 millisecondes pour une requête. Sous une charge légère, les deux s’influencent à peine ; quand la charge approche la capacité du système, le débit cesse de monter et la latence se met à grimper, et trouver ce point est précisément le rôle d’un test de charge.

L’exemple chiffré ci-dessous est un simple calcul, sans test derrière. Les définitions des outils viennent de la documentation de chaque projet, vérifiée le 16 octobre 2026.

	Débit	Latence	Bande passante
Question posée	Combien se termine par seconde ?	Combien de temps prend une unité ?	Combien la liaison pourrait-elle porter ?
Unité habituelle	requêtes ou transactions par seconde	millisecondes	mégabits par seconde
Dans k6	`http_reqs` (nombre et taux)	`http_req_duration`	pas une cible de test
Dans JMeter	Throughput	Elapsed time (et une « Latency » distincte)	pas une cible de test

Quelle est la différence entre débit et latence ?

Le débit compte le travail terminé dans le temps ; la latence mesure le temps que prend une unité de travail. Un système peut avoir une faible latence et un faible débit, ou un débit élevé et une latence élevée : il faut donc les deux chiffres pour le décrire.

Le glossaire de JMeter calcule le débit comme le nombre de requêtes divisé par le temps total, du début du premier échantillon à la fin du dernier, pauses entre échantillons comprises, puisqu’il doit représenter la charge sur le serveur (vérifié le 16 octobre 2026). Le débit est donc une propriété de toute l’exécution, alors que la latence appartient à chaque requête et se lit mieux comme une distribution : médiane, p95, p99.

La bande passante est-elle la même chose que le débit ?

Non. La bande passante est la quantité maximale de données qu’une liaison réseau pourrait porter ; le débit est ce qui passe réellement. En test de charge, le débit désigne en général des requêtes terminées, et la bande passante ne compte que lorsque de gros volumes de données remplissent la liaison avant que l’application n’atteigne sa capacité.

La page de comparaison d’AWS résume la vision réseau : la latence est le délai dans la communication réseau, le débit le volume moyen de données qui passe réellement sur une période, et la bande passante le maximum théorique (vérifié le 16 octobre 2026). Une grande partie de ce que l’on trouve en ligne emploie ce sens réseau. Le test de charge utilise les mêmes mots pour des requêtes plutôt que pour des paquets, d’où l’intérêt de préciser lequel un rapport désigne.

Que signifie « latence » dans un outil de test de charge ?

Cela dépend de l’outil. Dans JMeter, Latency est le temps jusqu’à la première partie de la réponse, et le temps de réponse complet s’appelle Elapsed time. Dans k6, http_req_duration couvre l’envoi, l’attente et la réception, et le temps jusqu’au premier octet est une métrique à part.

Le glossaire de JMeter mesure l’Elapsed time de juste avant l’envoi de la requête à juste après la réception de la dernière réponse, et la Latency jusqu’à juste après la réception de la première. La référence des métriques de k6 définit http_req_duration comme http_req_sending + http_req_waiting + http_req_receiving, sans résolution DNS ni établissement de connexion, et appelle http_req_waiting le temps jusqu’au premier octet (les deux vérifiés le 16 octobre 2026). La Latency de JMeter correspond donc à http_req_waiting dans k6, pas à http_req_duration. Comparez une « latence » JMeter à une « duration » k6 et le chiffre de JMeter paraîtra meilleur sans l’être.

Comment le débit et la latence évoluent-ils quand la charge augmente ?

Au début, plus de charge signifie plus de débit, et la latence reste à peu près stable. Une fois le système à sa capacité, le débit ne progresse plus et chaque utilisateur supplémentaire n’ajoute que de l’attente : la latence monte avec la charge.

Un exemple chiffré, simple calcul. Un service traite au plus 200 requêtes par seconde et répond en 0,1 seconde quand il n’est pas chargé. Chaque utilisateur virtuel envoie une requête puis fait une pause de 1 seconde. Avec un nombre fixe d’utilisateurs, la forme de la loi de Little pour le modèle fermé relie les grandeurs : utilisateurs = requêtes par seconde × (latence + temps de réflexion), comme le montre pas à pas notre article sur la loi de Little.

Utilisateurs virtuels	Débit (requêtes/s)	Latence (s)
50	45	0,1
150	136	0,1
220	200	0,1
300	200	0,5
400	200	1,0
600	200	2,0

Jusqu’à 220 utilisateurs, le débit progresse au même rythme qu’eux. Ensuite il reste bloqué à 200, et la latence doit absorber le reste : 300 utilisateurs demandent 300 ÷ 200 = 1,5 seconde par boucle, ce qui laisse 0,5 seconde de latence. Les systèmes réels fléchissent en général plus progressivement, car des files d’attente se forment avant le plafond exact. Avec un test à taux d’arrivée, la situation est pire : si les requêtes arrivent à plus de 200 par seconde, l’arriéré grossit tant que dure l’excédent, ce que l’article sur le modèle de charge ouvert ou fermé explique.

Comment repérer le coude dans vos propres résultats ?

Augmentez la charge par paliers, maintenez chaque palier assez longtemps pour qu’il se stabilise, et notez le débit et un percentile de latence pour chacun. Le coude est le premier palier où le débit ne suit plus la charge alors que la latence commence à grimper.

Quelques précautions rendent cette lecture fiable :

Maintenez chaque palier quelques minutes, pour mesurer le débit sur une phase stable et non sur une rampe.
Lisez un percentile, pas seulement la moyenne ; une moyenne peut rester calme pendant que les quelques pour cent de requêtes les plus lentes ralentissent nettement.
Vérifiez les erreurs à chaque palier. Les échecs rapides comptent comme des requêtes terminées avec des temps courts, si bien qu’un système défaillant peut afficher un débit en hausse et une latence en baisse.
Surveillez le générateur de charge. Si son CPU sature, le plafond trouvé est peut-être le sien.

Le graphique temps de réponse face aux utilisateurs virtuels de LoadFocus trace le temps de réponse moyen et maximal en fonction des utilisateurs virtuels actifs, un point par palier atteint, et c’est là que le coude apparaît dans un test par paliers.

Peut-on augmenter le débit sans augmenter la latence ?

Parfois. Ajouter de la capacité déplace le plafond, si bien que la latence reste plate plus longtemps. Le regroupement (batching) fait en général le compromis inverse : il augmente le débit en faisant attendre chaque requête.

L’algorithme de Nagle de TCP est l’exemple classique de ce compromis. La RFC 896 retient les nouveaux segments tant que des données déjà envoyées sur la connexion ne sont pas acquittées, de sorte que le réseau transporte moins de paquets, plus pleins, et que chaque petite écriture peut attendre (vérifié le 16 octobre 2026). Le regroupement de requêtes et la mise en tampon des écritures fonctionnent de la même façon : plus de travail par seconde, plus de temps par élément. Quand vous modifiez l’un d’eux, relancez le test par paliers et comparez les deux courbes, pas un seul chiffre.

Lequel des deux mettre dans vos critères de réussite ?

Les deux, liés. Un objectif de latence veut peu dire sans le débit auquel il a été mesuré, et un objectif de débit veut peu dire si la latence a doublé pour l’atteindre. Formulez-les comme une paire, par exemple p95 sous 300 millisecondes à 200 requêtes par seconde avec moins de 1 % d’erreurs.

Notre guide des critères de réussite d’un test de charge montre comment écrire et automatiser cette paire. Si votre outil attend les réponses lentes avant d’envoyer la requête suivante, ses chiffres de latence peuvent minimiser le problème ; la coordinated omission explique comment cela arrive et comment l’éviter. L’entrée du glossaire LoadFocus sur la latence détaille d’où vient la latence et pourquoi les percentiles comptent.

FAQ

Une faible latence signifie-t-elle un débit élevé ? Pas forcément. Un système peut répondre vite à chaque requête mais en traiter peu à la fois, ou en traiter beaucoup à la fois pendant que chacune attend. Vous ne connaissez les deux qu’après les avoir mesurés sous la même charge, idéalement sur plusieurs paliers.

Quelle est la différence entre latence et temps de réponse ? Dans l’usage courant, ils désignent souvent la même chose. Dans JMeter, Latency est le temps jusqu’à la première partie de la réponse et Elapsed time le temps de réponse complet : vérifiez lequel un rapport affiche avant de comparer des outils.

Pourquoi le débit cesse-t-il d’augmenter pendant un test de charge ? Quelque chose a atteint sa limite : le CPU, une base de données, un pool de connexions, une limitation de requêtes (rate limit) ou le générateur de charge lui-même. À partir de là, les utilisateurs supplémentaires ne font que patienter, ce qui se voit comme une latence en hausse à débit constant.