Alice déteste attendre

• Même si le temps moyen de requête d’un service est de 100 ms et que le MTTR est inférieur à 1 minute, les utilisateurs ont l’impression que le temps d’attente moyen est bien plus long, car ils restent plus longtemps coincés dans les requêtes longues et les longues pannes
• Les opérateurs agrègent les requêtes et les pannes par événement, mais des utilisateurs comme Alice et Alex comptent l’attente en secondes et minutes ressenties
• Cet écart vient du paradoxe de l’inspection : la distribution vécue par l’utilisateur n’est pas la distribution de latence d’origine f(t), mais une distribution pondérée par t
• Dans une distribution log-normale où le temps médian de reprise est de 30 minutes et le p99 de 600 minutes, même si le MTTR dépasse à peine 1 heure, le temps moyen de reprise ressenti par le client peut monter jusqu’à environ 6 heures
• Les latences de queue et les temps de reprise longs peuvent dominer l’expérience client, et la moyenne tronquée (trimmed mean) risque d’éliminer des informations importantes de la queue droite

---

L’écart entre la moyenne par requête et la moyenne ressentie par l’utilisateur

• Alice utilise un service web et, comme la plupart des gens, ressent le temps en secondes et en minutes
• Un opérateur peut voir qu’une requête moyenne se termine en 100 ms, mais le temps d’attente moyen d’Alice peut être de 1 seconde
• Le même décalage apparaît lors des pannes
  • Un opérateur peut dire que le MTTR est inférieur à 1 minute
  • Le temps moyen de panne ressenti par Alex peut être de 1 heure
• Les deux mesures peuvent être correctes en même temps
  • Dans les agrégations de l’opérateur, une requête longue ou une longue panne ne compte que comme un seul événement
  • Du point de vue du temps utilisateur, elles pèsent davantage à proportion de leur durée

La distribution pondérée par t créée par le paradoxe de l’inspection

• Ce phénomène peut être vu comme le paradoxe de l’inspection
• L’utilisateur ne fait pas l’expérience de la distribution de latence f(t) elle-même, mais d’une version pondérée par t
• Si le MTTR ou le temps moyen de requête est E[X], alors la moyenne vécue par l’utilisateur est la suivante
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• Plus la variance est grande, plus la moyenne ressentie par l’utilisateur s’écarte de la moyenne des métriques d’exploitation

Exemple avec une médiane à 30 minutes et un p99 à 600 minutes

• En prenant la latence médiane ou le temps de reprise médian ainsi que la valeur au 99e percentile, on peut ajuster une distribution log-normale et comparer les métriques du service aux valeurs ressenties par le client
• Les valeurs d’exemple sont les suivantes
  • TTR médian : 30 minutes
  • TTR p99 : 600 minutes, c’est-à-dire qu’1 événement sur 100 prend 10 heures à être résolu
• Dans ce cas, le MTTR dépasse légèrement 1 heure, mais le temps moyen de reprise vécu par le client atteint environ 6 heures

Les pièges des latences de queue et de la moyenne tronquée

• Il y a plusieurs raisons de comprendre les latences de queue et les temps de reprise longs, et multiple samples en fait partie
• Pour les temps de service, le timeout-and-retry peut masquer une partie de la latence
  • À condition toutefois que la requête en cours n’occupe pas un verrou ou une autre ressource exclusive
• Pour les temps de reprise, ce masquage est impossible, si bien que la lourdeur de la queue apparaît plus directement dans l’expérience client
• Des mesures tronquées comme la trimmed mean posent le problème de masquer la forme de la queue droite, alors qu’elle domine l’expérience client
• Une autre raison de ne pas préférer les mesures tronquées concerne la loi de Little et l’utilisation de capacité ; un texte lié est un article précédent

Précautions sur l’usage de la distribution log-normale

• La distribution log-normale est choisie ici pour la commodité des calculs numériques
• Elle a la propriété que lognormal(μ, σ²) devient lognormal(μ + σ², σ²), et elle se comporte bien près de 0
• Il est difficile de dire que la distribution log-normale est un choix particulièrement pertinent pour les métriques de latence ou de temps de reprise
• Pour ce type de problème, il vaut généralement mieux adopter une approche non paramétrique

[GN⁺]

Avis sur Lobste.rs

• Il vaudrait sans doute mieux remplacer le titre par quelque chose de plus informatif, comme Latency and the inspection paradox
  Dans son état actuel, le titre transmet en pratique presque zéro information 😅

  • Du point de vue de l’auteur, un titre un peu ambigu peut être assez utile
    parce que ça réduit les réponses de gens qui n’ont lu que le titre sans lire le contenu

• C’est intéressant, mais j’ai du mal à bien comprendre, parce que l’auteur n’explique pas vraiment pourquoi c’est vrai au-delà du terme t-weighted et des formules
  J’aurais aimé une explication plus claire, compréhensible même pour quelqu’un qui a oublié depuis longtemps son cours de statistiques à l’université

  • Imaginons qu’on ait un tableau de bord de monitoring : en général, on traite toutes les requêtes de la même façon pour calculer la latence moyenne

    mean = (sum of all latencies) / (number of requests)  
    

    C’est E[X], et le poids de chaque requête est 1/N
    La latence perçue par Alice est mesurée par rapport au temps, donc c’est probablement de là que vient la pondération par le temps (t-weighted)
    Si Alice a envoyé M requêtes de latence x_1, x_2, ..., x_M, on peut demander : « Si l’on choisit au hasard une seconde dans le temps d’attente total d’Alice, quelle est la latence de la requête pour laquelle elle attend à cet instant ? »
    Dans ce cas, la requête i contribue à hauteur de x_i / (Σ_j x_j), donc les requêtes longues sont davantage représentées
    La moyenne pondérée par le temps devient donc :

    E_a[X] = Σ_i x_i (x_i / Σ_j x_j) = Σ_i x_i^2 / Σ_j x_j  
    = (Σ_i x_i^2 / N) / (Σ_j x_j / N)  
    = E[X^2] / E[X]  
    

    Pour un exemple simple, s’il y a une requête avec 1 seconde de latence et une autre avec 10 secondes, la moyenne ordinaire est de 5,5 secondes, mais la moyenne pondérée par le temps devient 1 * (1 / 11) + 10 * 10 / 11 = 9.18s

• Sur le même sujet, The Inspection Paradox is Everywhere vaut aussi le détour

• Il m’est déjà arrivé d’avoir une réflexion similaire en pratique
  À mon avis, l’exemple le plus simple pour comprendre ce problème est une enquête où l’on demande aux passagers d’un bus combien de personnes se trouvent dans le bus
  On obtiendra alors bien plus souvent des réponses du type « le bus est bondé », mais quand le bus est vide, il n’y a personne à qui poser la question
  Tous les bus peuvent être vides, sauf un seul qui est bondé
  Si l’objectif est d’analyser la situation du point de vue de l’utilisateur, alors je pense que cette statistique est la bonne

  • Il existe un résultat similaire en théorie des graphes : presque tout le monde a des amis qui ont plus d’amis qu’eux
    parce que les nœuds très connectés apparaissent plus souvent dans la liste d’adjacence des autres nœuds que les nœuds peu connectés

• Si ce sujet vous parle, je recommande vivement Gil Tene's "How not to measure latency"