Qu'est-ce que la latence ?

Qu'est-ce que la latence ?

La latence est le temps entre le moment où un client envoie une requête et celui où il reçoit le premier byte de réponse. Dans un contexte web cela signifie : l'utilisateur clique, le browser envoie une requête HTTP, le serveur la traite, la réponse commence à arriver. Le temps horloge de ce round-trip est la latence, généralement exprimée en millisecondes.

Le chiffre end-to-end cache une pile de pièces contributrices : DNS lookup, handshake TCP, handshake TLS, traitement côté serveur (code applicatif, query base de données, appel API downstream), transmission de réponse. Une latence de 600 ms pourrait être 50 ms de DNS, 80 ms de TLS, 400 ms de traitement serveur et 70 ms de retour réseau. Trouver la pièce lente est le travail de performance engineering.

Latence vs throughput

Deux métriques, souvent confondues, qui mesurent des choses différentes :

• Latence : combien de temps prend une seule requête. Mesurée en millisecondes. Améliorer la latence rend les requêtes individuelles plus rapides.
• Throughput : combien de requêtes le système traite par unité de temps. Mesuré en RPS (requêtes par seconde). Améliorer le throughput signifie que le système sert plus d'utilisateurs sans ralentir.

Ils sont indépendants. Un système peut avoir une latence basse et un throughput bas (rapide pour un utilisateur, tombe à 100 utilisateurs). Il peut avoir une latence haute et un throughput haut (un pipeline batch qui traite des millions de records par seconde mais prend des minutes par record). Les systèmes de production ont besoin des deux.

Latence et throughput s'échangent sous charge. Ajoutez plus d'utilisateurs concurrents à un système à capacité fixe et la latence grimpe à mesure que les ressources sont disputées. La forme de cette montée est ce que load testing, capacity testing et scalability testing mesurent.

Pourquoi les moyennes trompent

La latence moyenne cache la queue. Si 99 requêtes reviennent en 100 ms et qu'une prend 30 secondes, la moyenne est 400 ms. Cela sonne bien mais correspond à un vrai utilisateur attendant 30 secondes. Les percentiles règlent cela :

• p50 (médiane) : la moitié des requêtes sont plus rapides. Utile comme sanity check, inutile pour les SLOs.
• p95 : 95% des requêtes sont plus rapides. Le seuil SLO de latence standard.
• p99 : 99% des requêtes sont plus rapides. Attrape la queue des outliers lents que p95 cache.
• p99,9 / max : les pires 0,1% des requêtes. Souvent dominés par les pauses GC, la contention de locks, les cold cache misses. Compte pour les systèmes high-traffic où 0,1% sont des millions d'utilisateurs.

Tout rapport de load test crédible montre des percentiles, jamais seulement des moyennes.

Sources de latence

1. Réseau. Distance géographique, temps de résolution DNS, handshake TCP / TLS. Un RTT de 100 ms de US à Europe est de la physique ; le round-trip ne peut pas être plus rapide que la lumière sur le câble. Les edges CDN réduisent cela en servant depuis une location plus proche.
2. Traitement côté serveur. Code applicatif, queries base de données, appels API downstream. Généralement la fraction la plus grande. Profilez pour trouver la pièce lente.
3. Garbage collection / pauses runtime. Pauses GC de JVM, pauses STW de Go, contention GIL de Python. Visible dans les queues p99+ comme des rafales de requêtes lentes.
4. Contention de ressources. Attentes sur pool de connexions DB, contention de locks, backlogs de queue. La latence grimpe abruptement quand la contention atteint la saturation ; c'est le coude sur la courbe du load test.
5. Rendu côté client. TTI (time to interactive) du browser inclut parse JS, hydratation, rendu. Pas latence au sens API mais compte pour la vitesse perçue par l'utilisateur.

Comment mesurer la latence

La latence est rapportée par chaque outil de load testing. Dans k6, la métrique intégrée http_req_duration rapporte p50, p95, p99 par défaut ; ajoutez thresholds: { http_req_duration: ['p(95)<500'] } pour faire échouer le test si p95 dépasse 500 ms. Dans JMeter, le listener Aggregate Report montre moyenne, médiane, p90, p95, p99.

Pour la latence de production, instrumentez le serveur avec un APM (Datadog, New Relic, Honeycomb) et le browser avec du RUM (real-user monitoring). La latence real-user inclut la longue queue de réseaux lents, de hardware mobile et de terminaison TLS partagée que les load tests synthétiques ne voient pas.

Exécutez des tests centrés latence depuis LoadFocus contre 25+ régions cloud pour voir comment la latence diffère par géographie. Une p95 de 50 ms depuis us-east-1 est sans pertinence si vos utilisateurs sont à Sydney et que la vraie p95 depuis là est 600 ms.

Si votre équipe a besoin d'une analyse de latence décomposée par endpoint, région et heure du jour contre une charge production-shape, LoadFocus propose des load testing services où des ingénieurs conçoivent la matrice de tests, exécutent les scénarios et rédigent la décomposition de latence.