Apdex (Application Performance Index) ist ein offener Standard, der Antwortzeiten in einen Zufriedenheitswert zwischen 0 und 1 übersetzt. Jede Anfrage gilt als zufrieden (höchstens Schwellwert T), tolerierend (über T bis 4T) oder frustriert (über 4T). Der Score ergibt sich als (zufrieden + tolerierend / 2) / Gesamtzahl.
Was Apdex ist
Apdex, kurz für Application Performance Index, ist ein offener Standard, um die Zufriedenheit von Nutzern mit der Reaktionsgeschwindigkeit einer Anwendung auszudrücken. Statt eines Latenz-Histogramms oder mehrerer Perzentile verdichtet Apdex alle Antwortzeiten eines Zeitfensters zu einer Zahl zwischen 0 (alle Nutzer frustriert) und 1 (alle Nutzer zufrieden). Die Apdex Alliance hat den Standard Mitte der 2000er-Jahre veröffentlicht, seitdem ist er in vielen APM-Werkzeugen eingebaut.
Das Prinzip ist einfach: Pro Anwendung oder Transaktion legen Sie genau einen Zielwert fest, den Schwellwert T. Alles Weitere leitet sich daraus ab.
Die Apdex-Formel
Jede Messung, meist eine Anfrage oder ein Seitenaufruf, fällt in eine von drei Zonen:
- Zufrieden (satisfied): Antwortzeit ≤ T.
- Tolerierend (tolerating): Antwortzeit > T und ≤ 4T.
- Frustriert (frustrated): Antwortzeit > 4T.
Der Score berechnet sich so:
Apdex_T = (zufrieden + tolerierend / 2) / Anzahl aller MessungenZufriedene Messungen zählen voll, tolerierende zur Hälfte, frustrierte gar nicht. Üblich ist die Schreibweise mit dem Schwellwert, etwa 0,91 [0,5] für einen Score von 0,91 bei T = 0,5 Sekunden. Die meisten Werkzeuge werten fehlgeschlagene Anfragen unabhängig von ihrer Dauer als frustriert, denn ein schneller Fehler ist kein gutes Erlebnis. Prüfen Sie dieses Verhalten, bevor Sie Werte aus verschiedenen Systemen vergleichen.
Die Apdex-Spezifikation schlägt Bewertungsstufen vor: 0,94 bis 1,00 exzellent, 0,85 bis 0,93 gut, 0,70 bis 0,84 ordentlich, 0,50 bis 0,69 schlecht und unter 0,50 inakzeptabel. Verstehen Sie diese Stufen als Orientierung, nicht als Vertragswert.
Rechenbeispiel
Eine beispielhafte Checkout-API hat T = 300 ms, die Frustrationsgrenze 4T liegt damit bei 1,2 s. In einem Fünf-Minuten-Fenster verarbeitet sie 10.000 Anfragen:
| Zone | Regel | Anfragen | Gewicht |
|---|---|---|---|
| Zufrieden | ≤ 300 ms | 8.800 | 1 |
| Tolerierend | 300 ms bis 1,2 s | 900 | 0,5 |
| Frustriert | > 1,2 s oder Fehler | 300 | 0 |
Apdex = (8.800 + 900 / 2) / 10.000 = 9.250 / 10.000 = 0,925, nach den Standardstufen also „gut“. Was die Zahl verschweigt: Die 300 frustrierten Anfragen können Timeouts bei einem einzigen Zahlungsanbieter sein oder ein langsamer Tail, der alle Nutzer gleichmäßig trifft. Um das zu unterscheiden, brauchen Sie weiterhin Traces und die Verteilung der Latenz.
Den Schwellwert T richtig wählen
T ist die wichtigste Entscheidung und wird trotzdem oft vernachlässigt. Viele Werkzeuge bringen einen Standardwert wie 0,5 Sekunden mit, der für eine interne 20-ms-API bedeutungslos und für einen Report-Export zu streng ist. Bewährt hat sich:
- T pro Transaktionstyp festlegen. Suche, Checkout und Datei-Upload wecken unterschiedliche Erwartungen.
- T aus Nutzererwartungen ableiten, nicht aus der aktuellen Performance. Wer T aus dem heutigen Median bestimmt, misst nur, dass sich nichts verändert hat.
- Für Frontends echte Nutzerdaten verwenden. Messen Sie Seiten im Browser per Real User Monitoring, denn die Serverzeit ist nur ein Teil der Wartezeit.
- T stabil halten. Jede Änderung an T verändert die Bedeutung aller historischen Werte.
Apdex im Vergleich zu Perzentilen und SLOs
Apdex lässt sich leicht kommunizieren, verdichtet aber Information. Zwei sehr unterschiedliche Verteilungen können denselben Score ergeben, und die starre 4T-Regel unterscheidet nicht zwischen einer Anfrage mit 1,3 s und einer mit 30 s. Deshalb bevorzugen die meisten SRE-Teams heute Latenz-SLOs wie „99 % der Checkout-Anfragen sind innerhalb von 28 Tagen schneller als 400 ms“. Ein SLO definiert zusätzlich Zeitfenster und Error Budget und eignet sich damit für Release-Entscheidungen. Apdex bleibt nützlich als schneller, normierter Gesundheitsindikator auf einem Dashboard und um Transaktionen mit unterschiedlichen Schwellwerten nebeneinander zu vergleichen.
Apdex in Frontend und Backend
Apdex lässt sich auf unterschiedliche Messgrößen anwenden, und das Ergebnis hängt stark davon ab, was Sie messen. Im Backend ist die Grundlage meist die Dauer des Server-Spans einer Transaktion. Im Browser zählt dagegen, wann die Seite für den Nutzer tatsächlich bereit ist, also inklusive Netzwerk, Rendering und Skriptausführung. Ein Backend-Score von 0,98 kann deshalb mit einem deutlich schlechteren Frontend-Score einhergehen. Halten Sie beide Sichten getrennt, benennen Sie die zugrunde liegende Messgröße eindeutig und vergleichen Sie nur Werte, die auf derselben Grundlage berechnet wurden. Synthetische Checks liefern zusätzlich einen stabilen Referenzwert, weil sie unter kontrollierten Bedingungen von festen Standorten aus messen.
Typische Fehler
- Ein globaler Standardwert für T über alle Services hinweg.
- Apdex-Werte von Services mit sehr unterschiedlichem Traffic mitteln, wodurch Endpunkte mit wenig Last zu stark gewichtet werden.
- Fehler ignorieren, sodass ein schnell scheiternder Service perfekt zufrieden wirkt.
- Bei kleinen Einbrüchen in verkehrsarmen Zeiten alarmieren, wenn wenige langsame Anfragen den Score stark bewegen.
Wie Obseria unterstützt
Obseria speichert Spans und RUM-Events mit Schema-on-Read in Obseria Lake. Zufriedene, tolerierende und frustrierte Anfragen lassen sich so aus den Rohdauern jedes Service oder jeder Seite ableiten, und Sie können später mit einem anderen Schwellwert neu rechnen. Ergänzend stehen Perzentile, Fehlerraten sowie SLOs mit Error Budgets zur Verfügung, die in jedem Tarif enthalten sind.