p95 und p99 statt Durchschnitt: Antwortzeiten messen

Warum der Durchschnitt der Antwortzeit trügt

Der arithmetische Mittelwert fasst alle Messwerte zu einer einzigen Zahl zusammen - und verliert dabei genau die Information, die zählt. In einer typischen Antwortzeitverteilung liegen die meisten Anfragen dicht beieinander, während wenige extrem langsame Ausreißer einen langen Schwanz nach rechts bilden. Der Mittelwert wird von diesen Ausreißern kaum bewegt, solange sie selten sind. Das Ergebnis: Ein Dashboard meldet 180 Millisekunden Durchschnitt, während das langsamste Prozent der Nutzer über eine Sekunde wartet. Wer nur den Mittelwert überwacht, sieht diese Verzögerung nie (Google SRE Book).

Ein konkretes Zahlenbeispiel macht das greifbar. Nehmen wir 10.000 Anfragen an einen Endpoint an. Der Median (p50) liegt bei 140 Millisekunden - die Hälfte aller Anfragen ist schneller, die Hälfte langsamer. Der Durchschnitt liegt mit 180 Millisekunden nur wenig höher und wirkt harmlos. Doch das 95. Perzentil (p95) steht bei 620 Millisekunden, und das 99. Perzentil (p99) bei 1.240 Millisekunden - fast das Neunfache des Medians. Anders gesagt: Jede hundertste Anfrage dauert länger als eine Sekunde, während der Durchschnitt unbeeindruckt bei 180 Millisekunden verharrt. Dieselbe Verteilung, zwei völlig verschiedene Geschichten - je nachdem, welche Kennzahl man liest.

Deshalb sollten Schwellenwerte im Monitoring nicht am Durchschnitt festgemacht werden, sondern an einem hohen Perzentil. Ein Grenzwert am Mittelwert schlägt erst an, wenn die Lage bereits flächendeckend schlecht ist; ein Grenzwert am p95 oder p99 reagiert, sobald ein relevanter Anteil der Nutzer leidet. Wie sich solche Grenzwerte als handfeste Prüfregeln definieren lassen, vertieft der Beitrag zu Schwellenwerten und Assertions im API-Monitoring.

Perzentile verstehen: p50, p95 und p99

Ein Perzentil ist ein einfacher, aber mächtiger Begriff. Das p-te Perzentil ist der Wert, unter dem p Prozent aller Messungen liegen. Ein p95 von 620 Millisekunden bedeutet: 95 Prozent aller Anfragen wurden in 620 Millisekunden oder schneller beantwortet, nur die langsamsten 5 Prozent brauchten länger. Ein p99 von 1.240 Millisekunden heißt entsprechend, dass 99 Prozent der Anfragen schneller waren und lediglich das langsamste Prozent darüber lag. Der Median ist nichts anderes als das p50 - die genaue Mitte der Verteilung.

• p50 (Median) - die typische Anfrage. Gut geeignet, um die normale Erfahrung der Mehrheit zu beschreiben, aber blind für Ausreißer.
• p95 - die Schwelle, ab der es unangenehm wird. Ein guter Kompromiss aus Stabilität und Empfindlichkeit; erfasst spürbare Verzögerungen, ohne bei jedem Extremwert zu springen.
• p99 - das langsamste Prozent. Zeigt die echten Ausreißer, die Timeouts und Abbrüche verursachen. Empfindlich, aber genau deshalb aussagekräftig für kritische Pfade.
• p99,9 - für Hochlast-Systeme. In großen verteilten Architekturen betrifft selbst ein Promille noch sehr viele Nutzer pro Tag.

Der entscheidende Vorteil: Perzentile beschreiben, was ein realer Anteil der Nutzer tatsächlich erlebt. Während der Durchschnitt eine abstrakte Rechengröße ist, die kein einzelner Nutzer je erfährt, entspricht das p95 einer konkreten Aussage - einer von zwanzig wartet mindestens so lange. Genau diese Übersetzbarkeit in echte Nutzererfahrung macht Perzentile zur Grundlage jedes ernsthaften Antwortzeit-Monitorings.

Long-Tail-Latenz: wenn ein Prozent alles bestimmt

Warum ist das langsamste Prozent so wichtig? Weil es sich in verteilten Systemen dramatisch verstärkt. Die vielzitierte Analyse The Tail at Scale von Dean und Barroso liefert das klassische Rechenbeispiel: Ein Server antwortet typischerweise in 10 Millisekunden, hat aber ein 99. Perzentil von einer Sekunde. Wird eine Nutzeranfrage von einem einzigen solchen Server bedient, ist nur eine von hundert Anfragen langsam (Dean und Barroso, The Tail at Scale).

Doch moderne Anwendungen bedienen eine einzige Nutzeranfrage selten mit einem einzigen Server. Muss die Anfrage Antworten von 100 solchen Servern parallel einsammeln, dann dauern bereits 63 Prozent aller Nutzeranfragen länger als eine Sekunde (Dean und Barroso, The Tail at Scale). Aus einem scheinbar seltenen Ein-Prozent-Problem wird die Mehrheitserfahrung. Und selbst wenn nur eine von 10.000 Anfragen auf Server-Ebene über einer Sekunde liegt, sieht ein Dienst mit 2.000 beteiligten Servern fast jede fünfte Nutzeranfrage über der Sekundengrenze (Dean und Barroso, The Tail at Scale).

Das 99. Perzentil eines Backends kann leicht zum Median der Antwortzeit Ihres Frontends werden.

— Google SRE Book, Monitoring Distributed Systems

Dieselbe Arbeit dokumentiert die Verstärkung an einem realen Google-Dienst: Das 99. Perzentil für eine einzelne zufällige Teilanfrage liegt bei 10 Millisekunden. Das 99. Perzentil dafür, dass alle Teilanfragen einer Nutzeranfrage fertig sind, springt jedoch auf 140 Millisekunden - und das Warten auf die langsamsten 5 Prozent der Teilanfragen ist für die Hälfte dieser gesamten 99-Perzentil-Latenz verantwortlich (Dean und Barroso, The Tail at Scale). Der lange Schwanz ist also kein Randphänomen, sondern der dominierende Kostenfaktor der Antwortzeit.

In der Praxis addieren sich viele kleine Quellen zu diesem Schwanz: ein langsamer Datenbank-Query, ein überlaufender Garbage Collector, eine Cache-Verfehlung, ein TLS-Handshake, der länger dauert als erwartet. Wer die Antwortzeit je Endpoint überwacht, findet die Quelle - der Beitrag zum zuverlässigen Überwachen von REST-Endpoints zeigt das Vorgehen. Auch die Wahl der Verschlüsselung spielt hinein: Wer den Umstieg auf hybride Post-Quantum-Verfahren im TLS-Monitoring plant, sollte die Latenzwirkung des größeren Handshakes gezielt im p95 und p99 mitmessen statt im Durchschnitt untergehen zu lassen.

Core Web Vitals: warum Google im 75. Perzentil misst

Dass Perzentile die richtige Linse sind, zeigt sich nirgends deutlicher als bei den Core Web Vitals - Googles Kennzahlen für die echte Nutzererfahrung im Web. Google bewertet eine Seite nicht am Durchschnitt ihrer Ladezeiten, sondern am 75. Perzentil aller Seitenaufrufe, getrennt nach Mobil- und Desktop-Geräten (web.dev). Damit ist sichergestellt, dass die Mehrheit der Besuche das Zielniveau tatsächlich erreicht - der Wert wurde bewusst so gewählt, dass die meisten Nutzer die angestrebte Leistung erleben (web.dev).

Die drei aktuellen Kennwerte und ihre Schwellen für gut lauten: Largest Contentful Paint (LCP) unter 2,5 Sekunden für die Ladezeit, Cumulative Layout Shift (CLS) von 0,1 oder weniger für die visuelle Stabilität (web.dev) und Interaction to Next Paint (INP) von 200 Millisekunden oder weniger für die Reaktionsfähigkeit (Chrome for Developers). Alle drei werden am 75. Perzentil des Feldes bewertet, nicht am Durchschnitt - eine bewusste methodische Entscheidung.

INP ist dabei die jüngste Ergänzung: Am 12. März 2024 löste Interaction to Next Paint die frühere Kennzahl First Input Delay als Core Web Vital ab (Chrome for Developers). Der Grund passt exakt zum Perzentil-Gedanken - First Input Delay maß nur die erste Interaktion, während INP die Latenz aller Interaktionen einer Sitzung betrachtet und damit die langsamen Ausreißer im Verlauf eines Besuchs sichtbar macht (Chrome for Developers).

Wie sich diese Werte im Feld verbessern lassen, behandeln die Beiträge zur Core-Web-Vitals-Optimierung und speziell zum Optimieren der anspruchsvollen Kennzahl INP. Bei Single-Page-Anwendungen kommt eine Besonderheit hinzu, die der Beitrag zu Core Web Vitals und Soft-Navigationen erklärt. Die Chrome-Felddaten selbst werden konsequent am 75. Perzentil ausgewiesen (Chrome for Developers) - ein weiterer Beleg, dass reine Durchschnitte für die Bewertung der Nutzererfahrung ausgedient haben.

p95 und p99 als Schwellen fürs Uptime- und API-Monitoring setzen

Aus den Perzentilen werden praktische Monitoring-Schwellen. Die Faustregel: Legen Sie Grenzwerte an einem Perzentil fest, das zur Kritikalität des Pfades passt. Für eine normale Marketing-Seite genügt oft ein p95-Ziel; für einen Bezahl- oder Login-Endpoint, bei dem jede Verzögerung Umsatz kostet, gehört zusätzlich das p99 überwacht. Der Median dient als Referenz für die Normallage, alarmiert aber nicht - er reagiert zu träge auf Ausreißer, um als Alarmgeber zu taugen.

Feste Schwellen sind ein guter Start, stoßen aber an Grenzen, sobald die Last tageszeitabhängig schwankt. Eine morgens auffällige Antwortzeit kann zur Mittagsspitze völlig normal sein und trotzdem denselben festen Grenzwert reißen. Hier hilft eine adaptive Baseline, die das erwartete Perzentil je Wochenstunde lernt und nur bei echten Abweichungen alarmiert. Wie synthetische Prüfungen ganze Nutzerpfade statt einzelner Endpoints messen, zeigt der Beitrag zum Browser-Monitoring mit synthetischen Checks.

Aus Perzentilen echte Alert-Regeln und SLO-Ziele ableiten

Perzentile sind der natürliche Baustein für Latenz-SLOs. Ein Verfügbarkeits-SLO beschreibt, wie oft ein Dienst erreichbar ist; ein Latenz-SLO beschreibt, wie schnell er antwortet - und formuliert sich fast immer über ein Perzentil. Ein typisches Ziel lautet: 95 Prozent aller Anfragen werden in unter 500 Millisekunden beantwortet, gemessen über 30 Tage. Damit wird aus einer diffusen Erwartung eine prüfbare Zusage, an der sich das Team messen lassen kann.

An diese Latenz-SLOs lassen sich dieselben Mechaniken knüpfen wie an Verfügbarkeits-SLOs: ein Fehlerbudget für die Anfragen jenseits der Schwelle und mehrstufige Alarme, die nach dem Verbrauchstempo unterscheiden. Wie sich daraus Burn-Rate-Alarme und Fehlerbudgets bauen lassen, vertieft der Beitrag zu Error-Budget und Burn-Rate im SLO-Monitoring.

1. Perzentil wählen - p95 für normale Pfade, p99 für kritische; den Median nur als Referenz führen
2. Zielwert setzen - eine konkrete Schwelle je Endpoint, abgeleitet aus der beobachteten Verteilung statt aus dem Bauch
3. Messfenster definieren - das Perzentil über ein rollierendes Fenster von etwa 30 Tagen berechnen, um Tagesschwankungen auszugleichen
4. Alarm staffeln - schnelle Benachrichtigung bei starkem Verbrauch, ruhiges Ticket bei langsamer Erosion
5. Regelmäßig nachschärfen - die Schwelle an die reale Verteilung anpassen, wenn sich Nutzung oder Infrastruktur ändern

Antwortzeit ist zudem nur eine Dimension der Dienstqualität. Für die E-Mail-Zustellung etwa greifen ganz andere, transportbezogene Sicherungen - der Beitrag zu MTA-STS und TLS-RPT für die Mailverschlüsselung zeigt, wie sich auch dort Qualität kontinuierlich überwachen lässt. Ein gutes Monitoring denkt Antwortzeit, Verfügbarkeit und Sicherheit zusammen statt in getrennten Silos.

Antwortzeiten mehrknotig erfassen

Perzentile sind nur so belastbar wie die Messung dahinter - und eine Messung von einem einzigen Ort verzerrt das Bild. Ein langsamer Netzweg zwischen einem einzelnen Prüfpunkt und Ihrem Server treibt das p95 nach oben, ohne dass ein echter Nutzer betroffen wäre; umgekehrt bleibt eine regionale Störung unentdeckt. XICTRAQ misst die Antwortzeit deshalb aus drei verteilten Standorten und weist die Perzentile je Endpoint aus - so trennen sich Netzeffekte von echten Verzögerungen.

Die lückenlose Antwortzeit-Historie liefert zugleich die Datenbasis, aus der sich p95, p99 und ihre Entwicklung über die Zeit berechnen lassen. Aus dieser Historie werden Schwellen, Alarme und Latenz-SLOs - alles an einem hohen Perzentil festgemacht statt am trügerischen Durchschnitt. Das Uptime-Monitoring von XICTRAQ verbindet diese Messung mit mehrstufigem Alerting per E-Mail, Slack, Discord oder Telegram.

Der Wechsel vom Durchschnitt zum Perzentil ist keine kosmetische Änderung, sondern eine andere Sicht auf dieselben Daten - eine, die zeigt, was Nutzer erleben, statt was die Statistik glättet. Wer p95 und p99 misst, erkennt Probleme, bevor sie zu Abbrüchen und Support-Tickets werden, und kann handeln, solange noch Spielraum ist.

Häufig gestellte Fragen zu Antwortzeit-Perzentilen