API Performance Metrics: Latency, Throughput, Error Rate
API-Performance-Metrics tracken Speed, Kapazität, Zuverlässigkeit — Latency p50/p95/p99, Throughput (RPS), Error-Rate, Saturation.
Was sind API-Performance-Metrics?
API-Performance-Metrics sind quantitative Measures, wie eine API unter echtem oder simuliertem Load behavt. Sie beantworten: Wie schnell respondet sie? Wie viel Traffic kann sie handhaben? Wie oft failt sie? Zusammen bilden diese Metrics die Basis von SLAs, SLOs und Capacity-Planning.
Die vier Golden Signals
| Signal | Was es misst | Beispiel |
|---|---|---|
| Latency | Zeit pro Request | p95 = 250ms |
| Throughput | Requests pro Zeit-Unit | 1.500 RPS |
| Errors | Failed-Request-Rate | 0,3% 5xx |
| Saturation | Wie "voll" das System ist | CPU 80% |
Latency: Perzentile, nicht Averages
| Perzentil | Was es Ihnen sagt |
|---|---|
| p50 (Median) | Typischer Request |
| p95 | 5% der User sehen das oder schlimmer |
| p99 | 1% sehen das oder schlimmer |
| p99.9 | 0,1% — schlimmste Erfahrungen |
| Max | Schlimmster Single-Request |
Throughput: Requests per Second (RPS)
- RPS
- QPS
- Concurrent Users / VUs
- Bandwidth
Error-Rate
- 5xx-Errors — Server-Faults
- 4xx-Errors — Client-Errors
- Timeouts
- Connection-Errors
Saturation
- CPU-Utilization
- Memory-Usage
- Disk-I/O
- Network-Bandwidth
- Queue-Depth
- Open File-Descriptors
- Thread/Connection-Counts
Application-spezifische Metrics
| Metric | Was es sagt |
|---|---|
| TTFB | Server-Response-Time vor Payload |
| Total Response-Time | End-to-End Latency |
| DNS-Lookup-Time | Network-Resolution |
| Connection-Time | TCP/TLS-Handshake |
| Database-Query-Time | Wie viel Latency ist DB |
| Apdex-Score | 0-1 Satisfaction-Score |
| Conversion-Rate | Business-Outcome |
SLI / SLO / SLA
| Term | Meaning | Beispiel |
|---|---|---|
| SLI | Die Metric selbst | p95-Latency |
| SLO | Internes Target | p95 < 500ms |
| SLA | Customer-facing Contract | 99,9% Uptime |
| Error-Budget | Wie viel Sie failen können | 43m/Monat at 99,9% |
Wie API-Performance gemessen wird
Synthetic / Load-Testing
Tools: JMeter, k6, Locust, Gatling.
Real User Monitoring (RUM)
Tools: Datadog, New Relic, Sentry.
APM
Tools: Datadog APM, New Relic APM, Dynatrace, OpenTelemetry.
Logs + Metrics + Traces
OpenTelemetry-Standard.
API-Performance Best Practices
- Messen, nicht raten.
- Perzentile tracken.
- SLOs definieren.
- Auf Burn-Rate alerten.
- Über expected Load testen.
- Saturation monitoren.
- Per Endpoint + Version taggen.
- Per Region/Browser/Device slicen.
- Continuous Load-Testing in CI.
Häufige Fallstricke
- Averages reporten.
- Nur in Staging messen.
- Keine SLO-Disziplin.
- Auf alle 5xx alerten.
- Single-Tool-Reliance.
- Performance einmal getestet.
- Tail-Latency ignorieren.
FAQ: API-Performance-Metrics
Was ist eine gute API-Latency?
Web-APIs: p95 < 500ms.
Wie finde ich meinen Max-Throughput?
Load-Test increasing RPS bis Latency degradiert.
Was ist eine acceptable Error-Rate?
Meist SLOs: < 0,1% 5xx.
p95 vs p99: was tracken?
Beide.
Wie ist Throughput related zu Capacity?
Capacity ist max sustainable Throughput.
Was ist ein Error-Budget?
Die Menge an Unreliability allowed by einem SLO.
Wie oft sollte ich Load-Testen?
Continuously in CI.
API-Performance mit LoadFocus messen
LoadFocus läuft JMeter- und k6-Scripts aus 25+ Regionen. Registrieren bei loadfocus.com/signup.
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um — derselben Plattform, die alles antreibt, was du gerade gelesen hast.