Skip to content

Glossary

Latence

Temps entre requête et réponse

By Published Updated

La latence est le temps entre l’envoi d’une requête et l’arrivée de la réponse. Dans les systèmes en réseau, elle se mesure en millisecondes ; dans les systèmes distribués, parfois en microsecondes ; dans la latence perçue par l’utilisateur, en centaines de millisecondes où les humains commencent à le remarquer.

Trois mesures que chaque ingénieur devrait connaître sur la latence d’un service :

  • Latence moyenne. Généralement trompeuse. Un seul outlier lent la tire vers le haut.
  • Latence médiane (p50). L’expérience d’une requête typique. Plus honnête que la moyenne.
  • Latences de queue (p95, p99, p99,9). Le 95e, 99e, 99,9e percentile des temps de réponse. p99 signifie « 1 % des requêtes sont plus lentes que ceci. » Pour les systèmes orientés utilisateur, p99 capture l’expérience des utilisateurs malchanceux.

Pourquoi les queues importent : à l’échelle, chaque utilisateur touche la queue tôt ou tard. Un service avec 100 ms de p50 et 5000 ms de p99 a des performances typiques rapides et des gels occasionnels de 5 secondes. Un utilisateur effectuant 100 requêtes dans une session touchera probablement la queue au moins une fois.

Sources de latence dans une requête HTTP typique :

  • DNS : 1-50 ms première recherche, ~0 en cache.
  • Connexion TCP : 1 aller-retour (RTT).
  • Connexion TLS : 1-2 RTT supplémentaires.
  • Traitement serveur : très variable, de microsecondes à secondes.
  • Propagation réseau : ~5 ms NY-Chicago, ~70 ms NY-Londres, ~150 ms NY-Sydney. Borne inférieure : vitesse de la lumière.

Pour les performances API réelles, la distribution par percentile importe bien plus que la moyenne. Ne rapporter que la latence moyenne est l’une des manières classiques dont les tableaux de bord de surveillance induisent en erreur.

Pourquoi p99 est la métrique qui définit « semble cassé » : un service où 99 % des requêtes prennent moins de 100 ms mais 1 % prennent 5 secondes semble cassé à chaque utilisateur qui touche le chemin lent. Le calcul : si un chargement de page typique effectue 50 appels backend et que p99 est 5 s, alors la probabilité que l’utilisateur touche au moins un appel lent est 1 − (0,99)⁵⁰ ≈ 40 %. Presque une page sur deux est lente. Améliorer la médiane est invisible ; réduire p99 améliore directement la performance perçue. Le manuel SRE de Google a codifié ce principe (« la latence de queue est la latence »), et la convention s’est répandue dans l’industrie. Référence : Dean & Barroso — The Tail at Scale (CACM, 2013).

Exemple de calcul : répartition du budget sur une requête

Cible : 200 ms p95 pour une page de paiement depuis un utilisateur américain. L’aller-retour lumière NY-Londres est d’environ 70 ms ; c’est le plancher pour tout appel transatlantique. Un fan-out typique : 50 ms TLS + économies de réutilisation de connexion, 40 ms lecture DB régionale, 60 ms autorisation de paiement tiers, 20 ms rendu HTML, 30 ms hydratation côté client. En les additionnant naïvement, on obtient 200 ms — sans aucune marge pour les nouvelles tentatives, les pauses GC ou les perturbations de voisinage bruyant. La correction est structurelle : déplacer l’appel de paiement hors du chemin critique (différer après la redirection), mettre en cache la lecture DB en edge pendant 60 s, et utiliser HTTP/3 sur QUIC pour intégrer TLS dans la configuration de connexion. Chacun réduit la queue de 30 à 50 ms.

Comment l’instrumenter correctement

Agréger par moyenne efface la forme même de la distribution dont vous avez besoin. Échantillonnez les timings bruts ou utilisez des histogrammes HDR (bibliothèque HdrHistogram de Gil Tene, portée dans la plupart des langages) qui préservent les percentiles à faible coût. Calculez les percentiles par région, par endpoint, par version — une régression globale de 5 ms en p99 peut signifier une régression de 200 ms dans une seule région masquée par la moyenne. Méfiez-vous de « l’omission coordonnée » : les générateurs de charge qui attendent une requête lente avant d’émettre la suivante sous-estiment p99 d’ordres de grandeur. Voir aussi percentile et médiane. Pour la décomposition RTT au niveau du protocole, la spécification RFC 9000 QUIC documente l’établissement de connexion 0-RTT et 1-RTT qui réduit matériellement la latence de handshake.

Frequently asked questions

Qu’est-ce que la latence ?
La latence est le temps écoulé entre l’envoi d’une requête et la réception du premier octet de la réponse. Elle est généralement mesurée en millisecondes et comporte trois composantes principales : le délai de propagation (vitesse de la lumière sur la distance), le délai de traitement (calcul serveur) et le délai de mise en file d’attente (congestion réseau).
Comment la latence diffère-t-elle du débit ?
La latence mesure le délai pour une seule requête ; le débit mesure combien de requêtes ou d’octets par seconde un système peut gérer. Un système peut avoir un débit élevé et une latence élevée simultanément — comme un navire cargo transportant de nombreux conteneurs lentement.
Pourquoi les équipes surveillent-elles la latence p95 ou p99 plutôt que la moyenne ?
Les moyennes masquent l’expérience dans le pire cas. Le 99e percentile (p99) capture ce que vivent les 1 % d’utilisateurs les plus lents, souvent 5 à 10 fois supérieur à la médiane. Les SLA et la satisfaction des utilisateurs sont généralement rompus par les latences de queue, pas par la médiane.
Quel est un budget de latence réaliste pour le chargement d’une page web ?
Une cible courante est moins de 200 ms pour le premier affichage de contenu, décomposé approximativement en : 50 ms DNS + TLS, 50 ms traitement serveur, 100 ms allers-retours réseau et rendu. Chaque appel API supplémentaire, chaque échec CDN ou script synchrone s’ajoute au total.

Related

Published May 16, 2026 · Last reviewed May 31, 2026