Latence de queue : définition et mesure sous charge

Q: La latence de queue est-elle la même chose que le p99 ?

Le p99 est la façon la plus courante de l'exprimer, et la queue désigne toute l'extrémité lente de la distribution. Suivez aussi le p99,9 et le maximum quand l'exécution compte assez de requêtes.

Q: Pourquoi mon p99 est-il tellement plus élevé que ma moyenne ?

Parce que quelques requêtes lentes bougent à peine la moyenne et définissent entièrement le p99. Un grand écart est normal ; un écart qui grandit avec la charge signale en général des files d'attente.

Q: Combien de requêtes faut-il pour mesurer le p99 ?

Au minimum quelques milliers par transaction, pour que le p99 repose sur des dizaines de requêtes lentes. Pour le p99,9, prévoyez des dizaines de milliers.

19 octobre 2026 7 min de lecture

La latence de queue est le temps de réponse des quelques requêtes les plus lentes, généralement exprimé par le 99e ou le 99,9e percentile. Elle compte parce qu’une action d’utilisateur attend souvent de nombreuses requêtes : un retard qui touche 1 requête sur 100 peut alors atteindre la plupart de vos utilisateurs. Un test de charge qui n’affiche que la moyenne ou la médiane ne la montre pas.

Appels backend par page	Part des pages qui subissent au moins un appel lent (1 sur 100)
1	1,0 %
5	4,9 %
10	9,6 %
20	18,2 %
50	39,5 %
100	63,4 %

Le tableau suppose que chaque appel est lent avec 1 % de probabilité, indépendamment des autres : la part vaut 1 - 0.99^n.

Qu’appelle-t-on la queue ?

La queue est la partie de la distribution des temps de réponse située au-delà d’un percentile élevé, le plus souvent p99 et p99,9. La médiane décrit une requête typique, la queue décrit les requêtes dont les gens se plaignent.

Un percentile est un seuil : p99 = 800 ms signifie que 99 % des requêtes ont pris 800 ms ou moins et 1 % plus longtemps. Sur un histogramme des temps de réponse, la queue se trouve à droite de ce seuil, souvent sous la forme d’une longue traîne fine loin du pic principal. Notre guide débit vs latence explique comment les outils de test de charge mesurent la latence et les percentiles.

Pourquoi la latence de queue compte-t-elle autant ?

Parce que les requêtes se multiplient. Une page ou un appel d’API qui se répartit sur de nombreux services ne se termine que lorsque le plus lent a répondu, et la queue de chaque service devient l’expérience habituelle de l’ensemble.

La référence est « The Tail at Scale » de Jeffrey Dean et Luiz André Barroso, publié dans Communications of the ACM en 2013 (PDF de l’article, vérifié le 19 octobre 2026). Leur exemple : un serveur qui répond d’habitude en 10 ms mais met une seconde au 99e percentile. Si une requête touche un seul de ces serveurs, 1 requête d’utilisateur sur 100 est lente. Si elle doit rassembler les réponses de 100 serveurs en parallèle, 63 % des requêtes d’utilisateurs dépassent une seconde. Même avec un seul appel lent sur 10 000, un service de 2 000 serveurs voit près d’une requête sur cinq dépasser une seconde.

Ils citent aussi des mesures d’un vrai service de Google : le 99e percentile d’une seule requête feuille était de 10 ms, mais il atteignait 140 ms pour que toutes les requêtes feuilles se terminent, et l’attente des 5 % les plus lentes en représentait la moitié.

Qu’est-ce qui cause la latence de queue ?

Le plus souvent, des interférences dues à d’autres tâches sur la machine ou dans le réseau. La même requête est rapide la plupart du temps et lente quand il se passe autre chose.

Dean et Barroso citent les suspects habituels :

Ressources partagées : d’autres tâches sur la même machine qui se disputent les cœurs CPU, les caches du processeur, la bande passante mémoire ou réseau.
Démons en arrière-plan qui se réveillent et prennent une part de la machine.
Tâches de maintenance comme le compactage de journaux ou le garbage collection des environnements managés.
Files d’attente dans les serveurs et les commutateurs réseau, qui amplifient toutes les autres sources.
Limites de puissance et de température qui ralentissent un CPU après un pic de travail.

En test de charge, la même liste prend la forme de pauses GC dans des services JVM ou Node.js, d’un pool de connexions épuisé, d’une requête SQL lente que seules certaines requêtes déclenchent, de caches froids après un déploiement et de nouvelles tentatives après un timeout. Une queue qui grandit avec la charge indique des files d’attente ; une queue présente même à faible charge indique quelque chose de périodique, comme le GC ou une tâche planifiée.

Comment mesurer la latence de queue dans un test de charge ?

Collectez assez d’échantillons, demandez à votre outil les bons percentiles et ne faites jamais la moyenne de percentiles entre machines ou fenêtres de temps.

Assez d’échantillons. Le p99 dépend du 1 % de requêtes le plus lent : une exécution de 500 requêtes le fait donc reposer sur 5 d’entre elles. Pour un p99 stable, il faut des milliers de requêtes par transaction, et des dizaines de milliers pour le p99,9. Les tests de fumée courts sont utiles pour repérer des erreurs et peu fiables pour juger la queue.

Les bons percentiles. Les réglages par défaut s’arrêtent souvent avant la queue. Dans k6, summaryTrendStats vaut par défaut avg,min,med,max,p(90),p(95), donc le p99 n’apparaît que si vous l’ajoutez (référence des options k6, vérifiée le 19 octobre 2026) :

k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
  script.js

L’Aggregate Report de JMeter affiche les lignes 90 %, 95 % et 99 %, et les propriétés aggregate_rpt_pct1 à aggregate_rpt_pct3 changent les percentiles affichés (vérifié le 19 octobre 2026).

Pas de moyenne de percentiles. Le p99 d’une exécution entière n’est ni la moyenne des p99 de chaque minute ni celle des p99 de chaque générateur de charge. Fusionnez les échantillons bruts ou un histogramme, puis calculez le percentile une seule fois. L’article sur la coordinated omission présente HdrHistogram, l’outil habituel pour cela, et un second piège : un générateur qui attend les réponses lentes envoie moins de requêtes pendant que le système ralentit, ce qui masque justement la queue que vous cherchez.

LoadFocus, qui publie ce site, affiche pour chaque exécution des tuiles P95 et P99, un histogramme des temps de réponse construit à partir des échantillons individuels et les requêtes les plus lentes : une longue traîne à droite du pic se voit d’un coup d’œil.

Comment fixer une limite de réussite sur la queue ?

Placez une limite sur le p99 pour chaque transaction clé, à côté d’une limite de p95 et d’une limite de taux d’erreur. Fondez-la sur les besoins des utilisateurs de cette transaction, et faites durer l’exécution assez longtemps pour que le p99 soit stable.

Un jeu raisonnable pour une API de paiement pourrait être : p95 sous 400 ms, p99 sous 1 200 ms, erreurs sous 0,5 %. Dans k6, ce sont des seuils sur http_req_duration comme p(99)<1200, et un seuil franchi fait sortir k6 avec un code différent de zéro (seuils k6, vérifié le 19 octobre 2026). LoadFocus propose un champ Max P99 response time à côté de Max P95 pour les tests cloud, JMeter et k6, et chaque exécution reçoit alors un PASS ou un FAIL. Notre guide sur les critères de réussite d’un test de charge couvre le reste du jeu.

Si vous publiez aussi un score Apdex, rappelez-vous qu’il range toute requête au-delà de quatre fois T dans une seule case et ne distingue donc pas une queue à 2 secondes d’une queue à 30 secondes. Le p99, si.

Comment réduire la latence de queue ?

Supprimez les sources de variabilité quand c’est possible, et concevez les appelants pour qu’un appel lent ne bloque pas toute la réponse.

Les correctifs courants, à peu près du moins coûteux au plus lourd :

Régler le GC et la taille des pools pour que les pauses et l’attente d’une connexion libre restent courtes sous charge.
Garder de la marge. Les files d’attente explosent près de la saturation, donc de la capacité libre raccourcit la queue ; le guide débit vs latence montre comment trouver le coude.
Fixer des timeouts et limiter les nouvelles tentatives pour qu’un appel bloqué échoue vite au lieu d’accumuler la file derrière lui.
Utiliser des requêtes couvertes (hedged requests) pour les lectures idempotentes : envoyer une seconde copie à un autre réplica si le premier n’a pas répondu à temps. Dean et Barroso décrivent l’envoi de la copie seulement après la latence attendue du 95e percentile, ce qui limite la charge supplémentaire à environ 5 %. Dans un de leurs tests, une copie envoyée après 10 ms a fait passer le 99,9e percentile de 1 800 ms à 74 ms, avec seulement 2 % de requêtes en plus.
Réduire le fan-out. Moins d’appels backend par page signifie moins de risques de tomber dans la queue, comme le montre le tableau du début.

Après chaque changement, relancez le même test avec le même profil de charge et comparez p99 et p99,9 d’une exécution à l’autre.

FAQ

La latence de queue est-elle la même chose que le p99 ? Le p99 est la façon la plus courante de l’exprimer, et la queue désigne toute l’extrémité lente de la distribution. Suivez aussi le p99,9 et le maximum quand l’exécution compte assez de requêtes.

Pourquoi mon p99 est-il tellement plus élevé que ma moyenne ? Parce que quelques requêtes lentes bougent à peine la moyenne et définissent entièrement le p99. Un grand écart est normal ; un écart qui grandit avec la charge signale en général des files d’attente.

Combien de requêtes faut-il pour mesurer le p99 ? Au minimum quelques milliers par transaction, pour que le p99 repose sur des dizaines de requêtes lentes. Pour le p99,9, prévoyez des dizaines de milliers.