Tail-Latenz: was sie ist und wie man sie misst

Tail-Latenz ist die Antwortzeit der wenigen langsamsten Anfragen, meist als 99. oder 99,9. Perzentil angegeben. Sie zählt, weil eine Nutzeraktion oft auf viele Anfragen wartet, sodass eine Verzögerung, die 1 von 100 Anfragen trifft, die meisten Ihrer Nutzer erreichen kann. Ein Lasttest, der nur Durchschnitt oder Median meldet, zeigt sie nicht.

Die Tabelle nimmt an, dass jeder Aufruf unabhängig von den anderen mit 1 % Wahrscheinlichkeit langsam ist: Der Anteil ist 1 - 0.99^n.

Was zählt zum Tail?

Der Tail ist der Teil der Antwortzeitverteilung oberhalb eines hohen Perzentils, meist p99 und p99,9. Der Median beschreibt eine typische Anfrage, der Tail die Anfragen, über die sich Leute beschweren.

Ein Perzentil ist eine Grenze: p99 = 800 ms heißt, 99 % der Anfragen brauchten 800 ms oder weniger und 1 % länger. Der Tail liegt in einem Antwortzeit-Histogramm rechts dieser Grenze, oft als langer, dünner Ausläufer weit weg vom Hauptgipfel. Unser Leitfaden zu Durchsatz vs. Latenz erklärt, wie Lasttest-Tools Latenz und Perzentile messen.

Warum ist Tail-Latenz so wichtig?

Weil sich Anfragen vervielfachen. Eine Seite oder ein API-Aufruf, der an viele Dienste verteilt wird, ist erst fertig, wenn der langsamste antwortet, und so wird der Tail jedes Dienstes zur typischen Erfahrung des Ganzen.

Die Standardquelle ist „The Tail at Scale“ von Jeffrey Dean und Luiz André Barroso, 2013 in Communications of the ACM erschienen (Paper als PDF, geprüft am 19. Oktober 2026). Ihr Beispiel: ein Server, der meist in 10 ms antwortet, beim 99. Perzentil aber eine Sekunde braucht. Berührt eine Anfrage einen solchen Server, ist 1 von 100 Nutzeranfragen langsam. Muss sie Antworten von 100 solchen Servern parallel einsammeln, dauern 63 % der Nutzeranfragen länger als eine Sekunde. Selbst wenn nur 1 von 10.000 Aufrufen langsam ist, sieht ein Dienst mit 2.000 Servern fast jede fünfte Anfrage über einer Sekunde.

Dean und Barroso berichten außerdem von Messungen aus einem echten Google-Dienst: Das 99. Perzentil für eine einzelne Leaf-Anfrage lag bei 10 ms, bis alle Leaf-Anfragen fertig waren aber bei 140 ms, und das Warten auf die langsamsten 5 % davon machte die Hälfte aus.

Was verursacht Tail-Latenz?

Meist Störungen durch andere Arbeit auf der Maschine oder im Netzwerk. Dieselbe Anfrage ist meist schnell und nur dann langsam, wenn gerade etwas anderes passiert.

Dean und Barroso nennen die üblichen Verdächtigen:

• Geteilte Ressourcen: andere Arbeit auf derselben Maschine, die um CPU-Kerne, Prozessor-Caches, Speicher- oder Netzwerkbandbreite konkurriert.
• Hintergrund-Daemons, die aufwachen und sich einen Teil der Maschine nehmen.
• Wartungsarbeit wie Log-Kompaktierung oder Garbage Collection in verwalteten Laufzeitumgebungen.
• Warteschlangen in Servern und Netzwerk-Switches, die jede andere Quelle verstärken.
• Leistungs- und Temperaturgrenzen, die eine CPU nach einer Lastspitze bremsen.

Im Lasttest tauchen dieselben Punkte als GC-Pausen in JVM- oder Node.js-Diensten auf, als erschöpfter Verbindungspool, als langsame Datenbankabfrage, die nur manche Anfragen auslösen, als kalte Caches nach einem Deploy und als Wiederholungen nach einem Timeout. Ein Tail, der mit der Last wächst, deutet auf Warteschlangen; ein Tail, der schon bei geringer Last da ist, deutet auf etwas Periodisches wie GC oder einen geplanten Job.

Wie misst man Tail-Latenz im Lasttest?

Sammeln Sie genug Samples, fragen Sie Ihr Tool nach den richtigen Perzentilen und mitteln Sie Perzentile nie über Maschinen oder Zeitfenster.

Genug Samples. p99 wird vom langsamsten 1 % der Anfragen bestimmt, ein Lauf mit 500 Anfragen stützt ihn also auf 5 davon. Für ein stabiles p99 brauchen Sie Tausende Anfragen pro Transaktion, für p99,9 Zehntausende. Kurze Smoke-Tests eignen sich gut, um Fehler zu finden, und schlecht, um den Tail zu beurteilen.

Die richtigen Perzentile. Standardwerte hören oft vor dem Tail auf. Bei k6 ist summaryTrendStats standardmäßig avg,min,med,max,p(90),p(95), p99 erscheint also nur, wenn Sie es hinzufügen (k6-Optionsreferenz, geprüft am 19. Oktober 2026):

k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
  script.js

Der Aggregate Report von JMeter zeigt die 90-%-, 95-%- und 99-%-Linien, und die Properties aggregate_rpt_pct1 bis aggregate_rpt_pct3 legen fest, welche Perzentile erscheinen (geprüft am 19. Oktober 2026).

Keine gemittelten Perzentile. Das p99 eines ganzen Laufs ist weder der Durchschnitt der p99-Werte jeder Minute noch der Durchschnitt der p99-Werte jedes Lastgenerators. Führen Sie die Roh-Samples oder ein Histogramm zusammen und berechnen Sie das Perzentil einmal. Der Artikel zu Coordinated Omission behandelt HdrHistogram, das übliche Werkzeug dafür, und eine zweite Falle: Ein Lastgenerator, der auf langsame Antworten wartet, schickt weniger Anfragen, während das System langsam ist, und verbirgt genau den Tail, den Sie suchen.

LoadFocus, der Herausgeber dieser Website, zeigt pro Lauf P95- und P99-Kacheln, ein Antwortzeit-Histogramm aus den einzelnen Samples und die langsamsten Anfragen, sodass ein langer Ausläufer rechts vom Gipfel auf einen Blick sichtbar ist.

Wie setzt man ein Pass/Fail-Limit auf den Tail?

Setzen Sie ein Limit auf p99 pro wichtiger Transaktion, neben ein p95-Limit und ein Fehlerraten-Limit. Leiten Sie es aus dem ab, was die Nutzer dieser Transaktion brauchen, und lassen Sie den Lauf lang genug laufen, damit p99 stabil ist.

Eine sinnvolle Kombination für eine Checkout-API könnte lauten: p95 unter 400 ms, p99 unter 1.200 ms, Fehler unter 0,5 %. In k6 sind das Schwellenwerte auf http_req_duration wie p(99)<1200, und ein verletzter Schwellenwert lässt k6 mit einem Exit-Code ungleich null enden (k6-Thresholds, geprüft am 19. Oktober 2026). LoadFocus hat neben Max P95 ein Feld Max P99 response time für Cloud-, JMeter- und k6-Tests, und jeder Lauf wird dann mit PASS oder FAIL bewertet. Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests behandelt die übrigen Kriterien.

Wenn Sie auch einen Apdex-Score melden, denken Sie daran, dass er jede Anfrage über dem Vierfachen von T in dieselbe Kategorie wirft und einen Tail von 2 Sekunden nicht von einem mit 30 Sekunden unterscheiden kann. Das p99 kann es.

Wie senkt man Tail-Latenz?

Beseitigen Sie Quellen der Schwankung, wo es geht, und bauen Sie Aufrufer so, dass ein langsamer Aufruf nicht die ganze Antwort aufhält.

Übliche Maßnahmen, grob von günstig bis aufwendig:

• GC und Poolgrößen abstimmen, damit Pausen und das Warten auf eine freie Verbindung unter Last kurz bleiben.
• Reserve einplanen. Warteschlangen wachsen kurz vor der Sättigung stark, freie Kapazität verkürzt also den Tail; der Leitfaden zu Durchsatz vs. Latenz zeigt, wie Sie den Knick finden.
• Timeouts setzen und Wiederholungen begrenzen, damit ein hängender Aufruf schnell scheitert, statt dass sich alles dahinter staut.
• Abgesicherte Anfragen (Hedging) für idempotente Lesezugriffe nutzen: eine zweite Kopie an ein anderes Replikat schicken, wenn das erste nicht rechtzeitig antwortet. Dean und Barroso beschreiben, die Reserveanfrage erst nach der erwarteten Latenz des 95. Perzentils zu senden, was die Zusatzlast auf etwa 5 % begrenzt. In einem ihrer Tests senkte ein Hedge nach 10 ms das 99,9. Perzentil von 1.800 ms auf 74 ms, bei nur 2 % mehr Anfragen.
• Weniger Fan-out. Weniger Backend-Aufrufe pro Seite heißt weniger Chancen, den Tail zu treffen, wie die Tabelle oben zeigt.

Führen Sie nach jeder Änderung denselben Test mit demselben Lastprofil erneut aus und vergleichen Sie p99 und p99,9 zwischen den Läufen.

FAQ

Ist Tail-Latenz dasselbe wie p99? p99 ist die üblichste Art, sie anzugeben, und der Tail ist das ganze langsame Ende der Verteilung. Verfolgen Sie auch p99,9 und das Maximum, wenn der Lauf genug Anfragen hat.

Warum ist mein p99 so viel höher als mein Durchschnitt? Weil ein paar langsame Anfragen den Durchschnitt kaum bewegen und das p99 vollständig bestimmen. Eine große Lücke ist normal; eine Lücke, die mit der Last wächst, deutet meist auf Warteschlangen.

Wie viele Anfragen brauche ich, um p99 zu messen? Mindestens einige Tausend pro Transaktion, damit das p99 auf Dutzenden langsamer Anfragen beruht. Für p99,9 planen Sie Zehntausende ein.

Weiterlesen

• Coordinated Omission: was es ist und wie man es vermeidet
• Durchsatz vs. Latenz: wie sie unter Last zusammenhängen
• Apdex-Score: was er bedeutet und wie man ihn berechnet
• Pass/Fail-Kriterien für Lasttests: so legen Sie sie fest
• Little’s Law im Lasttest: Tests dimensionieren und prüfen
• YCSB: Workloads A-F, Ausführung und Grenzen
• SLO vs. SLA: der Unterschied, SLIs und Fehlerbudgets

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.