Alice hasst Warten

• Selbst wenn die durchschnittliche Anfragedauer eines Dienstes 100 ms beträgt und die MTTR unter 1 Minute liegt, empfinden Nutzer die durchschnittliche Wartezeit als deutlich länger, weil sie in langen Anfragen und langen Ausfällen länger feststecken.
• Betreiber aggregieren Anfragen und Ausfälle als einzelne Ereignisse, aber Nutzer wie Alice und Alex rechnen Warten in subjektiv erlebter Zeit in Sekunden und Minuten.
• Dieser Unterschied entsteht durch das Inspektionsparadoxon (inspection paradox), und die von Nutzern erlebte Verteilung ist nicht die ursprüngliche Verzögerungsverteilung f(t), sondern eine mit t gewichtete Verteilung.
• Bei einer lognormalen Verteilung mit einem Median der Wiederherstellungszeit von 30 Minuten und einem p99 von 600 Minuten steigt die von Kunden empfundene durchschnittliche Wiederherstellungszeit auf etwa 6 Stunden, obwohl die MTTR nur etwas über 1 Stunde liegt.
• Tail-Latency und lange Wiederherstellungszeiten können die Kundenerfahrung dominieren, und ein getrimmter Mittelwert (trimmed mean) birgt das Risiko, wichtige Informationen aus dem rechten Schwanz der Verteilung zu verwerfen.

---

Die Lücke zwischen dem Durchschnitt pro Anfrage und dem von Nutzern empfundenen Durchschnitt

• Alice nutzt einen Webdienst und empfindet Zeit, wie die meisten Menschen, in Sekunden und Minuten.
• Betreiber sehen, dass eine durchschnittliche Anfrage in 100 ms abgeschlossen wird, aber Alices durchschnittliche Wartezeit kann 1 Sekunde betragen.
• Dasselbe gilt bei Ausfällen.
  • Betreiber können sagen, dass die MTTR unter 1 Minute liegt.
  • Die von Alex empfundene durchschnittliche Ausfallzeit kann 1 Stunde betragen.
• Beide Messungen können gleichzeitig richtig sein.
  • Lange Anfragen oder lange Ausfälle sind in der Betreiber-Statistik jeweils nur ein einzelnes Ereignis.
  • In der Zeitwahrnehmung der Nutzer erhalten sie umso mehr Gewicht, je länger sie andauern.

Die durch das Inspektionsparadoxon entstehende t-gewichtete Verteilung

• Dieses Phänomen lässt sich als Inspektionsparadoxon verstehen.
• Nutzer erleben nicht die Verzögerungsverteilung f(t) selbst, sondern eine mit t gewichtete Version davon.
• Wenn MTTR oder durchschnittliche Anfragedauer E[X] ist, ergibt sich der von Nutzern erlebte Durchschnitt wie folgt:
  • E_a[X] = E[X²] / E[X]
  • E_a[X] = E[X] + Var(X) / E[X]
• Je größer die Varianz ist, desto weiter liegt der subjektiv empfundene Durchschnitt über dem Mittelwert der Betriebsmetriken.

Beispiel mit 30 Minuten Median und 600 Minuten p99

• Setzt man den Median der Verzögerung oder Wiederherstellungszeit und den Wert des 99. Perzentils ein, lässt sich eine lognormale Verteilung anpassen und der Vergleich zwischen Service-Metriken und Kundenerfahrung berechnen.
• Die Beispielwerte sind wie folgt:
  • Median TTR: 30 Minuten
  • p99 TTR: 600 Minuten, das heißt: Bei 1 von 100 Ereignissen dauert die Wiederherstellung 10 Stunden.
• In diesem Fall liegt die MTTR nur etwas über 1 Stunde, aber die von Kunden erlebte durchschnittliche Wiederherstellungszeit beträgt etwa 6 Stunden.

Tail-Latency und die Falle des getrimmten Mittelwerts

• Es gibt mehrere Gründe, Tail-Latency und lange Wiederherstellungszeiten zu verstehen; multiple samples ist einer davon.
• Bei Servicezeiten kann timeout-and-retry einen Teil der Verzögerung verbergen.
  • Voraussetzung ist allerdings, dass laufende Anfragen keine Locks oder andere exklusive Ressourcen halten.
• Bei Wiederherstellungszeiten ist ein solches Verbergen nicht möglich, sodass sich die Schwere des Tails direkter in der Kundenerfahrung zeigt.
• Getrimmte Kennzahlen wie der trimmed mean haben das Problem, die Form des rechten Tails zu verdecken, der die Kundenerfahrung dominiert.
• Ein weiterer Grund, getrimmte Kennzahlen nicht zu bevorzugen, hängt mit Little’s Law und der Kapazitätsauslastung zusammen; dazu gibt es einen früheren Beitrag.

Hinweis zur Verwendung der lognormalen Verteilung

• Die lognormale Verteilung wurde aus Gründen der numerischen Bequemlichkeit gewählt.
• Sie hat die Eigenschaft, dass lognormal(μ, σ²) zu lognormal(μ + σ², σ²) wird, und verhält sich in der Nähe von 0 gut.
• Das bedeutet nicht unbedingt, dass die lognormale Verteilung für Latenz- oder Wiederherstellungszeitmetriken eine besonders gute Wahl ist.
• Für solche Probleme ist ein nichtparametrischer Ansatz im Allgemeinen besser geeignet.

[GN⁺]

Lobste.rs-Kommentare

• Es wäre wohl besser, den Titel in etwas informativeres wie Latency and the inspection paradox zu ändern.
  Der aktuelle Titel vermittelt praktisch gar keine Information 😅

  • Aus Sicht des Autors ist ein leicht vager Titel ziemlich nützlich.
    Er reduziert nämlich Antworten von Leuten, die nur den Titel gelesen und den Text nicht gelesen haben.

• Interessant, aber ich verstehe nicht ganz, warum das stimmt, weil der Autor es außer mit dem Begriff t-weighted und einer Formel nicht erklärt.
  Ich wünschte, es wäre klarer erklärt, sodass es auch Leute verstehen, die ihre Statistikvorlesung aus dem Studium längst vergessen haben.

  • Angenommen, es gibt ein Monitoring-Dashboard; normalerweise behandelt man alle Requests gleich und berechnet die durchschnittliche Latenzzeit so:

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

    Das ist E[X], und das Gewicht jedes Requests ist 1/N.
    Die von Alice wahrgenommene Latenz ist zeitbasiert, daher kommt hier vermutlich das zeitgewichtete (t-weighted) Konzept ins Spiel.
    Wenn Alice M Requests mit den Latenzen x_1, x_2, ..., x_M gesendet hat, kann man fragen: „Wenn man zufällig 1 Sekunde aus Alices gesamter Wartezeit auswählt, wie hoch ist dann die Latenz des Requests, auf den sie in diesem Moment wartet?“
    Dabei trägt Request i mit x_i / (Σ_j x_j) bei, daher gehen lange Requests stärker ein.
    Deshalb ist der zeitgewichtete Mittelwert wie folgt:

    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]  
    

    Als einfaches Beispiel: Wenn es einen Request mit 1 Sekunde Latenz und einen mit 10 Sekunden Latenz gibt, dann beträgt der normale Mittelwert 5,5 Sekunden, der zeitgewichtete Mittelwert aber 1 * (1 / 11) + 10 * 10 / 11 = 9.18s.

• Dazu passend ist auch The Inspection Paradox is Everywhere lesenswert.

• Ich hatte tatsächlich schon einmal einen ähnlichen Gedanken.
  Das am leichtesten verständliche Beispiel für dieses Problem ist meiner Meinung nach eine Umfrage unter Busfahrgästen, bei der man fragt, wie viele Menschen im Bus sitzen.
  Dann bekommt man viel häufiger die Antwort „Der Bus ist voll“, aber wenn ein Bus leer ist, kann man niemanden fragen.
  Es könnte sein, dass alle Busse leer sind und nur genau einer voll ist.
  Wenn das Ziel ist, die Situation aus Nutzersicht zu analysieren, dann halte ich diese Statistik für richtig.

  • In der Graphentheorie gibt es ein ähnliches Ergebnis: Fast alle Menschen haben Freunde, die mehr Freunde haben als sie selbst.
    Das liegt daran, dass stark verbundene Knoten in den Adjazenzlisten anderer Knoten häufiger erscheinen als schwach verbundene.

• Falls euch dieses Thema anspricht, kann ich Gil Tene's "How not to measure latency" sehr empfehlen.