API-Performance-Metriken: Latenz, Durchsatz, Fehlerrate

Was sind API-Performance-Metriken?

API-Performance-Metriken messen, wie schnell eine API antwortet, wie viel Traffic sie verarbeitet und wie oft sie ausfällt, im echten Betrieb oder in einem Test. Die vier wichtigsten sind Latenz, Durchsatz, Fehlerrate und Auslastung. Teams setzen damit Ziele, finden Engpässe und entscheiden, wann skaliert werden muss.

Die vier Golden Signals

Das SRE-Buch von Google nennt vier Signale, die das Wichtigste an einem Dienst abdecken (siehe Monitoring Distributed Systems, auf Englisch). Die Beispielwerte unten sind rein illustrativ.

Latenz: Perzentile statt Durchschnitt

Der Durchschnitt versteckt den langsamen Rand. Das SRE-Buch nennt den klassischen Fall: Ein Dienst mit 100 ms Durchschnittslatenz bei 1.000 Anfragen pro Sekunde kann leicht bei 1 % der Anfragen 5 Sekunden brauchen. Berichten Sie deshalb Perzentile, mehr dazu in Warum Perzentile aussagekräftiger sind als Durchschnittswerte (Artikel auf Englisch).

Messen Sie die Latenz erfolgreicher und fehlgeschlagener Anfragen getrennt. Ein schneller Fehler kann die Zahlen besser aussehen lassen, als die Nutzer es erleben, und ein langsamer Fehler ist schlimmer als ein schneller. Grundlagen: Latenz.

Durchsatz

Durchsatz ist die Arbeitsmenge pro Zeiteinheit, bei einer API meist Anfragen pro Sekunde (RPS). Verwandte Größen sind gleichzeitige Nutzer (virtuelle Nutzer im Test) und Bandbreite. Allein sagt der Durchsatz wenig: Betrachten Sie ihn zusammen mit Latenz und Fehlern. Steigt die Latenz, während der Durchsatz nicht mehr wächst, ist das Ihre praktische Kapazitätsgrenze, siehe Zusammenhang von Durchsatz und Antwortzeit (auf Englisch).

Fehlerrate

Der Anteil der Anfragen, die scheitern. Teilen Sie sie nach Ursache auf, denn jede zeigt in eine andere Richtung:

• 5xx-Antworten: Serverfehler, Ihr Problem.
• 4xx-Antworten: meist Fehler des Clients (401, 404, 429), aber ein plötzlicher Anstieg kann auf ein fehlerhaftes Release oder ein abgelaufenes Zugangsdatum hindeuten.
• Timeouts und Verbindungsfehler: Die Anfrage wurde nie abgeschlossen.
• Falscher Inhalt trotz 200: Das SRE-Buch zählt auch das als Fehler. Prüfen Sie den Body, nicht nur den Statuscode.

Auslastung (Saturation)

Die Auslastung zeigt, wie nah das System an seiner Grenze ist. Viele Systeme werden schon deutlich vor 100 % Auslastung langsamer. Beobachten Sie CPU, Speicher, Disk-I/O, Netzwerk, Datenbank-Connection-Pool und Warteschlangenlänge und legen Sie einen Zielwert fest. Ein steigendes p99 in einem kurzen Zeitfenster ist oft das erste Anzeichen.

Weitere nützliche Zeiten

• Time to First Byte: Bearbeitungszeit auf dem Server, bevor die Nutzdaten kommen, siehe Time to First Byte (TTFB).
• DNS-, TCP-Verbindungs- und TLS-Zeit: Netzwerkaufwand, bevor Ihr Code überhaupt läuft.
• Download-Zeit: Größe der Antwort und Bandbreite.
• Aufschlüsselung nach Endpunkt und Region: Eine Gesamtzahl kann einen langsamen Endpunkt oder eine langsame Region verbergen.

SLI, SLO, SLA und Error Budget

Die 43 Minuten sind einfache Rechnung: 0,1 % eines 30-Tage-Monats (43.200 Minuten). Mehr zu Verträgen unter SLA-Management.

Ein durchgerechnetes Beispiel

Angenommen, Sie testen einen hypothetischen Endpunkt /orders mit 50, 100 und 200 virtuellen Nutzern. Bei 50 und 100 Nutzern bleibt p95 bei rund 180 ms, Fehler gibt es kaum. Bei 200 Nutzern springt p95 auf 900 ms und 2 % der Anfragen laufen in einen Timeout, während der Durchsatz gegenüber dem Lauf mit 100 Nutzern kaum gewachsen ist. Das Knie liegt bei etwa 100 Nutzern, das ist Ihre sichere Kapazität, und der Datenbank-Connection-Pool (eine Auslastungsmetrik) ist das Erste, was Sie prüfen.

So messen Sie die API-Performance

• Lasttests: kontrollierten Traffic vor einem Release erzeugen und Läufe vergleichen. Siehe Lasttest.
• Synthetisches API-Monitoring: geplante Prüfungen gegen die Produktion, die Antwortzeit, Status und Body erfassen. Siehe API-Monitoring.
• APM und Nutzerdaten: Instrumentierung auf dem Server und Felddaten zeigen, was echter Traffic erlebt. Siehe Application Performance Monitoring.

Keine Quelle sieht alles: Tests liefern eine reproduzierbare Baseline, Monitoring entdeckt Regressionen in der Produktion und APM erklärt die Ursache.

Häufige Fehler

• Nur Durchschnittswerte berichten. Der langsame Rand ist das, worüber sich Nutzer beschweren.
• Nur in Staging messen. Daten, Caches und Traffic-Mix unterscheiden sich in der Produktion.
• Keine Ziele. Metriken, die niemand mit einem SLO vergleicht, werden ignoriert.
• Alarm bei jedem 5xx. Alarmieren Sie lieber auf die Fehlerrate über ein Zeitfenster.
• Eine Zahl für alle Endpunkte. Nach Endpunkt und Version aufschlüsseln.
• Nur einmal testen. Nach größeren Änderungen erneut testen.

API-Performance messen mit LoadFocus

Der Lasttest von LoadFocus führt JMeter-, k6- und No-Code-Tests aus 25 Cloud-Regionen aus und meldet Antwortzeit, Latenz, Durchsatz, Fehler sowie das 50., 90. und 99. Perzentil, mit Pass-oder-Fail-Schwellen für p95 oder p99, Fehlerrate und Durchsatz. Das API-Monitoring prüft Ihre Endpunkte nach Zeitplan (im kostenlosen Tarif alle 5 Minuten) und kann eine Prüfung bei Status, Body, Headern oder Antwortzeit fehlschlagen lassen. Einen größeren Überblick gibt API-Testing.

Häufige Fragen: API-Performance-Metriken

Was ist eine gute API-Latenz?

Das hängt vom Anwendungsfall und von den Erwartungen der Nutzer ab. Viele Teams streben für interaktive Endpunkte ein p95 von wenigen hundert Millisekunden an, für interne oder Echtzeit-Aufrufe weniger. Leiten Sie das Ziel aus Ihren eigenen Nutzern ab und messen Sie p95 und p99, nicht den Durchschnitt.

Wie finde ich den maximalen Durchsatz einer API?

Führen Sie einen Lasttest aus, der den Traffic schrittweise erhöht, und beobachten Sie Latenz und Fehler. Der Punkt, an dem die Latenz steigt oder Fehler auftreten, obwohl der Durchsatz nicht mehr wächst, ist das praktische Maximum.

Welche Fehlerrate ist akzeptabel?

Es gibt keine allgemeingültige Zahl. Sie ergibt sich aus Ihrem SLO: Ein Zahlungs- oder Login-Endpunkt braucht eine viel niedrigere Rate als ein unkritischer. Legen Sie sie pro Endpunkt fest und messen Sie über ein Fenster wie 30 Tage.

Sollte ich p95 oder p99 verfolgen?

Beides. p95 beschreibt die Qualität für die meisten Nutzer, p99 die Erfahrung der Pechvögel. Bei viel Traffic sind selbst 1 % sehr viele Menschen.

Was ist ein Error Budget?

Die Menge an Ausfall, die Ihr SLO noch erlaubt. Bei 99,9 % Verfügbarkeit über 30 Tage sind es etwa 43 Minuten. Ist das Budget fast aufgebraucht, bremsen Teams meist riskante Releases und kümmern sich zuerst um Zuverlässigkeit.