1 points par GN⁺ 3 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp
  • Après le déploiement d’une nouvelle couche de cache, la latence moyenne s’est dégradée de 112 ms à 122 ms, mais la médiane s’est améliorée de 99 ms à 54 ms et le p99 s’est dégradé de 309 ms à 678 ms, ce qui rend difficile de juger du succès ou de l’échec à partir d’une seule statistique
  • Après le déploiement, la distribution des latences est passée d’un seul pic à deux pics ; en superposant les fonctions de répartition cumulée (CDF), on voit qu’autour de 140 ms se situe la frontière : les requêtes rapides s’améliorent, les requêtes lentes se dégradent
  • La fonction de décalage indiquant l’évolution par percentile, ainsi que les graphiques en ridgeline et les cartes thermiques quotidiennes, révèlent l’ampleur des améliorations et des régressions, ainsi que la croissance du groupe de requêtes lentes pendant que le taux de déploiement passe de 0 % à 100 %
  • En segmentant les données par résultat du cache et par taille de réponse, il est apparu que les hits de cache sur les petites réponses devenaient plus rapides, tandis que les miss de cache sur les grandes réponses ralentissaient à cause d’un saut supplémentaire, ce qui a permis d’identifier la cause de la distribution bimodale
  • Si l’on ne choisit que la moyenne ou un percentile précis, on peut justifier des conclusions opposées ; il faut donc examiner l’ensemble de la distribution et les sous-groupes pour déboucher sur des actions comme augmenter la taille maximale des objets en cache ou découper les grandes réponses

Une amélioration de performance invisible en production

  • Les améliorations de performance liées à lld apparaissaient dans les benchmarks, mais sur les tableaux de bord de production réels, le bruit des données rendait difficile l’identification d’un changement net
  • La vitesse de build peut varier fortement selon de nombreux facteurs : cache froid, builds incrémentaux, exécution locale ou distante, état du système, workload, etc.
  • Un exemple d’évaluation des performances de build avec une fonction de répartition cumulée (CDF) a montré qu’il fallait examiner les données elles-mêmes de plusieurs manières, plutôt que de se fier à une seule image ou statistique
  • Tous les exemples ont été générés à partir d’un unique jeu de données synthétique à graine fixe ; le script complet, avec un shebang nix-shell, permet de reproduire à l’identique chaque figure dans un environnement Nix
  • L’IA a été utilisée pour créer les données et les graphiques destinés au récit

Un déploiement de cache qui ressemblait à un échec vu par la moyenne

  • Pour réduire la latence des requêtes d’un service web, une nouvelle couche de cache a été déployée pendant une semaine, mais la latence moyenne a augmenté de 112 ms à 122 ms, soit +9 %
  • En ne regardant que la moyenne, il est facile de conclure à une régression justifiant un rollback, une réponse à incident et une analyse post-mortem

Quatre conclusions à partir des mêmes données

  • Les statistiques avant/après déploiement pointent dans des directions différentes
    • Moyenne : 112 ms → 122 ms, 9 % de dégradation
    • Médiane p50 : 99 ms → 54 ms, 46 % d’amélioration
    • p95 : 224 ms → 454 ms, 103 % de dégradation
    • p99 : 309 ms → 678 ms, 119 % de dégradation
  • La moyenne indique une légère régression, mais la médiane montre que les requêtes typiques sont devenues presque deux fois plus rapides, tandis que le p99 révèle un problème sérieux : les pires requêtes sont plus de deux fois plus lentes
  • Comme la moyenne et la médiane calculées sur les mêmes données indiquent des directions opposées, il devient facile de choisir uniquement la statistique qui soutient son jugement

Deux groupes de requêtes révélés par la forme de la distribution

  • Sur le graphique de densité, la distribution avant déploiement avait un seul pic, mais après le déploiement elle se divise en deux pics
  • Cette forme explique la contradiction entre les statistiques, mais les graphiques de densité ont aussi leurs limites
    • La forme dépend du paramètre de lissage choisi
    • Quand les zones remplies des deux distributions se chevauchent, la lecture devient difficile
    • La présence de deux groupes est visible, mais il est difficile d’identifier directement la position de percentiles comme la médiane

Comparer tous les percentiles avec une CDF

  • La fonction de répartition cumulée (CDF) indique, pour chaque latence x, la proportion de requêtes terminées en x millisecondes ou moins
  • En superposant les CDF avant et après déploiement sur un même graphique, on peut voir comment chaque percentile s’est déplacé dans l’ensemble des requêtes
  • Après le déploiement, la courbe se décale vers la gauche sous 140 ms, ce qui signifie que davantage de requêtes sont plus rapides qu’avant ; au-delà de 140 ms, davantage de requêtes deviennent plus lentes
  • Le point où les deux courbes se croisent, vers 140 ms, marque la frontière où l’effet du changement passe de l’amélioration à la dégradation
  • Lorsque deux CDF se croisent, le sens de l’effet dépend du percentile choisi : aucun percentile unique ne peut résumer l’ensemble du changement

Mesurer l’évolution à chaque percentile

  • La CDF montre quelles zones sont devenues plus rapides ou plus lentes, mais pas directement l’ampleur du changement
  • La fonction de décalage (shift function) calcule, pour chaque percentile p, la différence entre la latence après déploiement et la latence avant déploiement
    • Sous 0 : zone améliorée
    • Au-dessus de 0 : zone ralentie
  • Elle permet ainsi de voir non seulement le sens du changement à chaque point de la distribution, mais aussi son ampleur

Une régression qui grandit pendant le déploiement

  • La nouvelle couche de cache a été progressivement étendue de 0 % à 100 % du trafic sur une semaine ; comparer seulement deux instants, avant et après, fait perdre les changements intermédiaires
  • Sur un graphique en ridgeline, qui empile les distributions quotidiennes, le pic principal des requêtes rapides se déplace vers la gauche à mesure que le déploiement progresse, tandis qu’un second pic de requêtes lentes apparaît à droite
  • La médiane baisse, mais dans le même temps le nombre de requêtes lentes et leur latence augmentent discrètement
  • Les latences suivant approximativement une loi log-normale, l’axe x utilise une échelle logarithmique
    • Sur un axe linéaire, le pic des requêtes rapides domine et les requêtes lentes s’étalent faiblement, ce qui rend difficile la lecture simultanée des deux pics
  • Une carte thermique représentant les colonnes quotidiennes et le volume de trafic par niveau de latence fait aussi apparaître discrètement un nouveau groupe de requêtes
  • Si l’on agrège toute la semaine en une seule valeur, les sept distributions quotidiennes distinctes et leur tendance d’évolution disparaissent

Décomposer la distribution bimodale en hits et miss de cache

  • Dans l’analyse réelle de lld, il fallait segmenter les données par taille de binaire, par exemple selon qu’elle dépassait ou non 50 MiB, pour identifier la distribution bimodale des latences
  • Dans l’exemple synthétique, la nouvelle couche divise les requêtes entre hits traités par le cache et miss transmis au backend avec un saut supplémentaire
  • En séparant la CDF des requêtes après déploiement par résultat du cache, chaque groupe retrouve un seul pic
    • Les hits de cache se déplacent vers la gauche par rapport à la ligne de base, donc deviennent plus rapides
    • Les miss de cache se situent beaucoup plus à droite à cause du coût du saut supplémentaire

Cause et actions trouvées dans la taille des réponses

  • Les miss de cache ne sont qu’un mécanisme ; pour comprendre quelles requêtes causent des miss et pourquoi, il faut aussi examiner la taille des réponses
  • Le cache conserve les petits objets fréquemment utilisés, mais les gros objets sont évincés ou n’y entrent pas dès le départ
  • Dans un jointplot combinant la relation entre latence et taille de réponse, colorée par hit ou miss de cache, avec les distributions de densité sur chaque axe, les deux groupes apparaissent clairement
    • Le groupe petites réponses/faible latence correspond aux hits de cache
    • Le groupe grandes réponses/forte latence correspond aux miss de cache
  • La distribution bimodale des latences provient de la bimodalité de la distribution des tailles de réponse ; on peut y répondre en augmentant la taille maximale des objets en cache ou en découpant les grandes réponses

Voir toute la distribution au-delà d’un seul graphique

  • Un seul panneau ou graphique ne suffit pas à rendre compte de toute la situation et peut, dans certains cas, conduire à une mauvaise décision
  • Il faut examiner les mêmes données de plusieurs manières pour comprendre à la fois la forme de la distribution, les effets par percentile, l’évolution dans le temps, les sous-groupes et les causes
  • La CDF est particulièrement utile pour comparer plusieurs groupes de requêtes tout en représentant l’ensemble de la distribution dans un seul graphique

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.