Qu'est-ce que la latence ?

Qu'est-ce que la latence ?

La latence est le délai entre l'envoi d'une requête et la réception d'une réponse. Pour le trafic web, MDN définit la latence réseau comme le temps qu'un paquet de données met pour aller de la source à la destination, le plus souvent mesuré en aller-retour. Les outils de test de charge emploient souvent un sens plus étroit : le temps jusqu'à l'arrivée du premier octet de la réponse. Les deux se mesurent en millisecondes.

Latence, temps de réponse et TTFB : quel chiffre est lequel ?

Le mot recouvre trois notions voisines, et les outils ne s'accordent pas :

• Latence réseau : le temps de trajet entre deux machines, aller simple ou aller-retour (RTT). Elle dépend de la distance et du chemin, pas de votre code.
• Latence dans JMeter : d'après son glossaire, JMeter la mesure « de juste avant l'envoi de la requête à juste après la réception de la première réponse ». Le temps écoulé (elapsed time) court jusqu'à la réception de la dernière partie de la réponse.
• Time to first byte : la métrique http_req_waiting de k6 est le temps d'attente de la réponse, que k6 appelle lui-même TTFB. http_req_duration est l'envoi plus l'attente plus la réception, et l'établissement de la connexion est rapporté à part. Voir time to first byte.

Le temps de réponse est l'attente complète jusqu'à la fin de la réponse, ce que l'utilisateur ressent. Quand vous comparez deux rapports, vérifiez quelle définition chaque outil utilise. L'article de blog sur le temps de réponse en test de performance approfondit ce côté.

D'où vient la latence

• Établissement de la connexion. Selon MDN, la première requête comprend une résolution DNS, une poignée de main TCP et la négociation TLS. Les requêtes suivantes sur la même connexion en évitent l'essentiel.
• Distance. Un utilisateur éloigné du serveur paie plus de temps d'aller-retour à chaque étape. Un CDN le réduit pour le contenu pouvant être mis en cache.
• Travail du serveur. Le code applicatif, les requêtes de base de données et les appels à d'autres services apparaissent comme du temps d'attente avant le premier octet.
• Files d'attente sous charge. Quand des requêtes attendent une connexion, un thread ou un emplacement de base de données libre, la latence grimpe alors que chaque tâche reste identique.
• Taille du téléchargement. MDN indique que le temps de réception dépend de la capacité du réseau et de la taille de la ressource.

Latence et débit

La latence est la durée d'une requête. Le débit (throughput) est le nombre de requêtes que le système termine par unité de temps. Un système peut être rapide pour un utilisateur et s'effondrer à cent, il faut donc surveiller les deux ensemble. La façon dont la latence augmente avec la charge est ce que montrent les tests de charge et les tests de capacité. L'article comment débit et temps de réponse sont liés montre la forme de cette courbe.

Pourquoi les moyennes cachent le problème

Prenez 99 requêtes à 100 ms et une à 30 secondes. La moyenne est d'environ 400 ms, ce qui paraît correct, alors qu'un utilisateur a attendu une demi-minute. Les percentiles décrivent plutôt la distribution : p50 est la médiane, p95 signifie que 95 % des requêtes ont été plus rapides, p99 que 99 % l'ont été. L'article de Google The Tail at Scale explique pourquoi les réponses lentes rares pèsent davantage à mesure que les systèmes grandissent. Côté tests, lisez pourquoi les percentiles valent mieux que les moyennes.

Exemple : un seuil de latence dans un test

Avec k6, vous pouvez faire échouer une exécution quand la queue devient trop lente. Les expressions sont évaluées à la fin du test ; si l'une est fausse, le test échoue et k6 se termine avec un code différent de zéro :

thresholds: { http_req_duration: ['p(95) < 500', 'p(99) < 1000'] }

Les chiffres sont un exemple. Fixez les vôtres selon les besoins de vos utilisateurs et de votre SLA, pas selon une valeur par défaut.

Comment mesurer et réduire la latence

• Mesurez là où sont les utilisateurs. Les tests de charge LoadFocus s'exécutent depuis 25 régions cloud et rapportent temps de réponse, latence, débit, écart type et les percentiles 50, 90 et 99, avec des seuils de réussite ou d'échec sur P95 et P99. Un test depuis une seule région dit peu de chose des utilisateurs ailleurs.
• Surveillez en production. Le monitoring d'API suit le temps de réponse selon un calendrier (les contrôles gratuits tournent toutes les 5 minutes) et peut vous alerter quand un endpoint dépasse un seuil de dégradation. Les indicateurs utiles sont listés dans indicateurs de performance d'API. L'étude de cas réduire la latence d'une API montre la démarche.
• Réduisez le coût par requête. Réutilisez les connexions, mettez en cache ce qui peut l'être, servez les fichiers statiques depuis un CDN, réduisez le nombre de noms d'hôte et corrigez d'abord les requêtes lentes.

Erreurs courantes

• Ne rapporter que la moyenne.
• Tester depuis la même région que le serveur et généraliser à tous les utilisateurs.
• Comparer des chiffres d'outils qui définissent la latence différemment.
• Ignorer la première requête, qui porte le coût du DNS, de TCP et de TLS.
• Confondre un objectif de latence avec un objectif de débit.

Questions fréquentes : latence

Qu'est-ce qu'une bonne latence ?

Il n'existe pas de chiffre universel. Cela dépend du type de requête, de l'utilisateur et de votre SLA. Fixez un objectif sur un percentile comme p95, mesurez-le sous charge réaliste et depuis les régions de vos utilisateurs, puis resserrez-le au fil des améliorations.

Quelle est la différence entre latence et temps de réponse ?

La latence désigne généralement le délai avant le début de la réponse, ou le temps de trajet réseau. Le temps de réponse est l'attente complète jusqu'à la fin de la réponse. Les outils définissent les deux de façon légèrement différente, consultez donc la documentation de celui que vous utilisez.

Quelle est la différence entre latence et bande passante ?

La latence est un délai. La bande passante est la quantité de données que la connexion peut transporter par seconde. Un gros téléchargement est limité par la bande passante, une page avec beaucoup de petites requêtes par la latence.

En quoi la latence diffère-t-elle du TTFB ?

Le TTFB mesure le temps jusqu'au premier octet de la réponse, il contient donc la latence réseau plus le temps d'attente du serveur. Certains outils, dont JMeter, appellent ce chiffre la latence.

Pourquoi la latence p99 est-elle plus élevée que la p50 ?

La plupart des requêtes sont rapides et quelques-unes sont lentes à cause d'échecs de cache, du ramasse-miettes, de verrous ou de files d'attente. Le p99 montre ces quelques-unes, c'est pourquoi il faut le surveiller pour les pires expériences.