Der Durchschnitt sagt gar nichts aus

• Nach der Einführung einer neuen Cache-Schicht verschlechterte sich die durchschnittliche Latenz von 112 ms auf 122 ms, doch der Median verbesserte sich von 99 ms auf 54 ms und p99 verschlechterte sich von 309 ms auf 678 ms, sodass es schwierig ist, Erfolg oder Misserfolg nur anhand eines einzelnen statistischen Werts zu beurteilen
• Nach dem Rollout spaltete sich die Latenzverteilung von einem Gipfel in zwei Gipfel; legt man die kumulative Verteilungsfunktion (CDF) übereinander, zeigt sich, dass sich schnelle Anfragen bis etwa 140 ms verbessern, langsame Anfragen dagegen verschlechtern
• Die Shift Function, die die Veränderung je Perzentil zeigt, sowie tägliche Ridgeline-Plots und Heatmaps machen das Ausmaß von Verbesserung und Regression sichtbar und zeigen, wie die Gruppe langsamer Anfragen wächst, während der Rollout von 0 % auf 100 % steigt
• Teilt man die Daten nach Cache-Ergebnis und Antwortgröße auf, zeigt sich, dass Cache-Hits bei kleinen Antworten schneller werden, während Cache-Misses bei großen Antworten wegen eines zusätzlichen Hops langsamer werden; so lässt sich die Ursache der zweigipfligen Verteilung bestätigen
• Wählt man nur den Durchschnitt oder ein bestimmtes einzelnes Perzentil, lassen sich sogar gegensätzliche Bewertungen rechtfertigen; deshalb muss man die gesamte Verteilung und Untergruppen gemeinsam betrachten, um zu Maßnahmen wie einer höheren maximalen Cache-Objektgröße oder dem Aufteilen großer Antworten zu kommen

---

Eine Performance-Verbesserung, die in der Produktion unsichtbar blieb

• Die Performance-Verbesserungen rund um lld zeigten sich in Benchmarks, in echten Produktions-Dashboards war jedoch wegen des Datenrauschens kaum eine klare Veränderung zu erkennen
• Die Build-Geschwindigkeit kann je nach kaltem Cache, inkrementellem Build, lokaler oder entfernter Ausführung, Systemzustand, Workload und weiteren Variablen stark schwanken
• Ein Beispiel zur Bewertung der Build-Performance mit der kumulativen Verteilungsfunktion (CDF) machte deutlich, dass man die Daten selbst auf mehrere Arten betrachten muss statt sich auf ein einzelnes Bild oder einen einzelnen statistischen Wert zu verlassen
• Alle Beispiele wurden aus einem synthetischen Datensatz mit festem Seed erzeugt; das vollständige Skript enthält eine nix-shell-Shebang und kann die einzelnen Abbildungen in einer Nix-Umgebung unverändert reproduzieren
• Für die erzählerischen Daten und die Erstellung der Diagramme wurde AI verwendet

Ein Cache-Rollout, der im Durchschnitt wie ein Fehlschlag aussah

• Um die Anfrage-Latenz eines Webdienstes zu senken, wurde eine Woche lang eine neue Cache-Schicht ausgerollt, doch die durchschnittliche Latenz stieg um 9 %, von 112 ms auf 122 ms
• Betrachtet man nur den Durchschnitt, lässt sich die Änderung leicht als Regression einstufen, die ein Rollback sowie Incident Response und eine Nachanalyse rechtfertigt

Vier Urteile aus denselben Daten

• Die Statistiken vor und nach dem Rollout zeigen in unterschiedliche Richtungen
  • Durchschnitt: 112 ms → 122 ms, 9 % Verschlechterung
  • p50-Median: 99 ms → 54 ms, 46 % Verbesserung
  • p95: 224 ms → 454 ms, 103 % Verschlechterung
  • p99: 309 ms → 678 ms, 119 % Verschlechterung
• Der Durchschnitt zeigt eine leichte Regression, der Median dagegen, dass typische Anfragen fast doppelt so schnell wurden, und p99 weist auf ein schwerwiegendes Problem hin, bei dem die langsamsten Anfragen mehr als doppelt so langsam wurden
• Da Durchschnitt und Median, aus denselben Daten berechnet, in entgegengesetzte Richtungen zeigen, ist es leicht, nur die Statistik auszuwählen, die die eigene Einschätzung stützt

Die Verteilungsform legte zwei Anfragegruppen offen

• Im Dichteplot war die Verteilung vor dem Rollout eingipflig, nach dem Rollout spaltete sie sich jedoch in zwei Gipfel auf
• Diese Form erklärt die Widersprüche zwischen den statistischen Werten, aber auch Dichteplots haben Einschränkungen
  • Die Form hängt vom gewählten Glättungsparameter ab
  • Wenn sich die gefüllten Bereiche beider Verteilungen überlappen, werden sie schwer lesbar
  • Die Existenz zweier Gruppen ist sichtbar, aber die Lage von Perzentilen wie dem Median lässt sich nicht direkt ablesen

Mit der CDF die gesamten Perzentile vergleichen

• Die kumulative Verteilungsfunktion (CDF) zeigt für jede Latenz x den Anteil der Anfragen, die in x Millisekunden oder schneller abgeschlossen wurden
• Legt man die CDFs vor und nach dem Rollout in einem Diagramm übereinander, lässt sich erkennen, wie sich die einzelnen Perzentile über die gesamte Anfragepopulation hinweg verschoben haben
• Nach dem Rollout verschiebt sich die Kurve unterhalb von 140 ms nach links, sodass mehr Anfragen schneller als zuvor werden; nach 140 ms werden dagegen mehr Anfragen langsamer
• Der Schnittpunkt der beiden Kurven bei etwa 140 ms ist die Grenze, an der der Effekt der Änderung von Verbesserung zu Verschlechterung kippt
• Wenn sich zwei CDFs schneiden, hängt die Richtung des Effekts vom gewählten Perzentil ab; kein einzelnes Perzentil kann daher die gesamte Veränderung zusammenfassen

Die Veränderung für jedes Perzentil messen

• Die CDF zeigt, welche Bereiche schneller oder langsamer wurden, nicht aber direkt das Ausmaß der Veränderung selbst
• Die Shift Function berechnet für jedes Perzentil p die Differenz zwischen der Latenz nach dem Rollout und der Latenz davor
  • Werte unter 0 sind verbesserte Bereiche
  • Werte über 0 sind verlangsamte Bereiche
• So lässt sich an jedem Punkt der Verteilung nicht nur die Richtung, sondern auch das Ausmaß der Veränderung erkennen

Die wachsende Regression während des Rollouts

• Die neue Cache-Schicht wurde über eine Woche hinweg schrittweise von 0 % auf 100 % des Traffics erhöht; vergleicht man nur zwei Zeitpunkte vor und nach dem Rollout, entgehen einem die Veränderungen dazwischen
• In einem Ridgeline-Plot mit aufeinander gestapelten Tagesverteilungen verschiebt sich mit fortschreitendem Rollout der Hauptgipfel schneller Anfragen nach links, während rechts ein zweiter Gipfel langsamer Anfragen auftaucht
• Während der Median sinkt, nehmen Zahl und Latenz langsamer Anfragen still zu
• Die Latenz folgt ungefähr einer Lognormalverteilung, daher wird auf der x-Achse eine logarithmische Skala verwendet
  • Auf einer linearen Achse ragt der Gipfel schneller Anfragen hoch auf, während langsame Anfragen nur blass verteilt erscheinen, sodass sich beide Gipfel kaum gemeinsam lesen lassen
• Auch in der Heatmap, die tägliche Spalten und das Verkehrsaufkommen je Latenzbereich per Farbe darstellt, wird die neue Anfragegruppe schwach sichtbar
• Fasst man die gesamte Woche zu einem einzigen Aggregat zusammen, verschwinden sieben unterschiedliche Tagesverteilungen und der Verlauf der Veränderung

Die zweigipflige Verteilung nach Cache-Hits und -Misses zerlegen

• In der tatsächlichen lld-Analyse musste man die Daten nach Binärgröße aufteilen, etwa ob sie größer als 50 MiB sind, um die zweigipflige Latenzverteilung sichtbar zu machen
• In der neuen Schicht des synthetischen Beispiels teilen sich Anfragen in Hits, die im Cache bedient werden, und Misses, die an das Backend weitergeleitet werden und einen zusätzlichen Hop durchlaufen
• Trennt man die CDF der Anfragen nach dem Rollout nach Cache-Ergebnis, hat jede Gruppe wieder nur einen Gipfel
  • Cache-Hits verschieben sich gegenüber der bisherigen Basislinie nach links und werden schneller
  • Cache-Misses liegen wegen der Kosten des zusätzlichen Hops deutlich weiter rechts

Ursache und Maßnahmen in der Antwortgröße gefunden

• Cache-Misses sind nur der Wirkmechanismus; um zu verstehen, welche Anfragen warum Misses verursachen, muss man auch die Antwortgröße betrachten
• Der Cache hält kleine, häufig verwendete Objekte vor, während große Objekte verdrängt werden oder von vornherein nicht aufgenommen werden können
• In einem Jointplot, der die Beziehung zwischen Latenz und Antwortgröße nach Cache-Hit oder -Miss einfärbt und Dichteverteilungen an beiden Achsen kombiniert, treten die beiden Gruppen klar hervor
  • Die Gruppe mit kleinen Antworten und niedriger Latenz besteht aus Cache-Hits
  • Die Gruppe mit großen Antworten und hoher Latenz besteht aus Cache-Misses
• Die zweigipflige Latenzverteilung stammt aus der Zweigipfligkeit der Antwortgrößenverteilung; reagieren kann man darauf, indem man die maximale Cache-Objektgröße erhöht oder große Antworten aufteilt

Über ein einzelnes Diagramm hinaus die ganze Verteilung betrachten

• Ein einzelnes Panel oder Diagramm reicht nicht aus, um die gesamte Situation abzubilden, und kann je nach Fall sogar zu Fehlurteilen verleiten
• Erst wenn man dieselben Daten auf mehrere Arten betrachtet, lassen sich Verteilungsform, Perzentil-Effekte, zeitliche Veränderungen, Untergruppen und Ursachen gemeinsam verstehen
• Besonders die CDF ist nützlich, um mehrere Anfragegruppen zu vergleichen und zugleich die gesamte Verteilung in einem einzigen Diagramm darzustellen