Was ist Latenz?

Was ist Latenz?

Latenz ist die Zeit zwischen dem Senden eines Requests durch einen Client und dem Empfang des ersten Response-Bytes. In einem Web-Kontext bedeutet das: User klickt, Browser sendet einen HTTP-Request, Server verarbeitet ihn, Response beginnt anzukommen. Die Uhrzeit dieses Round-Trips ist Latenz, normalerweise in Millisekunden ausgedrückt.

Die End-to-End-Zahl versteckt einen Stack beitragender Teile: DNS-Lookup, TCP-Handshake, TLS-Handshake, serverseitige Verarbeitung (Applikations-Code, Datenbank-Query, Downstream-API-Call), Response-Übertragung. Eine 600-ms-Latenz könnte 50 ms DNS, 80 ms TLS, 400 ms Server-Verarbeitung und 70 ms Network-Return sein. Das langsame Teil zu finden, ist die Arbeit von Performance-Engineering.

Latenz vs Durchsatz

Zwei Metriken, oft verwechselt, die unterschiedliche Dinge messen:

• Latenz: wie lange ein einzelner Request dauert. Gemessen in Millisekunden. Latenz zu verbessern macht einzelne Requests schneller.
• Durchsatz: wie viele Requests das System pro Zeiteinheit verarbeitet. Gemessen in RPS (Requests pro Sekunde). Durchsatz zu verbessern bedeutet, das System bedient mehr Benutzer ohne langsamer zu werden.

Sie sind unabhängig. Ein System kann niedrige Latenz und niedrigen Durchsatz haben (schnell für einen User, kippt bei 100 Usern um). Es kann hohe Latenz und hohen Durchsatz haben (eine Batch-Pipeline, die Millionen Records pro Sekunde verarbeitet, aber Minuten pro Record braucht). Produktions-Systeme brauchen beides.

Latenz und Durchsatz tauschen sich unter Last ein. Mehr gleichzeitige Benutzer zu einem System bei fixer Kapazität hinzufügen, klettert die Latenz, wenn Ressourcen umkämpft werden. Die Form dieses Anstiegs ist, was Load Testing, Capacity Testing und Scalability Testing messen.

Warum Durchschnitte irreführen

Die durchschnittliche Latenz versteckt den Tail. Wenn 99 Requests in 100 ms zurückkehren und einer 30 Sekunden braucht, ist der Durchschnitt 400 ms. Klingt gut, mappt aber auf einen echten User, der 30 Sekunden wartet. Perzentile fixen das:

• p50 (Median): die Hälfte der Requests ist schneller als dies. Nützlich als Sanity Check, nutzlos für SLOs.
• p95: 95% der Requests sind schneller. Der Standard-Latenz-SLO-Schwellenwert.
• p99: 99% der Requests sind schneller. Fängt den Tail von langsamen Outliers, den p95 versteckt.
• p99,9 / max: die schlimmsten 0,1% der Requests. Oft dominiert von GC-Pausen, Lock Contention, Cold-Cache-Misses. Wichtig für High-Traffic-Systeme, wo 0,1% Millionen User sind.

Jeder glaubwürdige Load-Test-Report zeigt Perzentile, niemals nur Durchschnitte.

Quellen von Latenz

1. Network. Geografische Distanz, DNS-Auflösungszeit, TCP- / TLS-Handshake. Eine 100-ms-RTT von US nach Europa ist Physik; der Round-Trip kann nicht schneller sein als Licht über die Leitung. CDN-Edges reduzieren das, indem sie aus einer näheren Location bedienen.
2. Serverseitige Verarbeitung. Applikations-Code, Datenbank-Queries, Downstream-API-Calls. Normalerweise der größte Anteil. Profilen, um das langsame Teil zu finden.
3. Garbage Collection / Runtime-Pausen. JVM-GC-Pausen, Go-STW-Pausen, Python-GIL-Contention. Sichtbar in p99+-Tails als Bursts langsamer Requests.
4. Ressourcen-Contention. Datenbank-Connection-Pool-Waits, Lock Contention, Queue Backlogs. Latenz klettert scharf, wenn Contention Sättigung trifft; das ist der Ellbogen auf der Load-Test-Kurve.
5. Client-seitiges Rendering. Browser-TTI (Time to Interactive) inkludiert JS-Parse, Hydration, Render. Nicht Latenz im API-Sinn, aber wichtig für user-wahrgenommene Geschwindigkeit.

Wie Latenz messen

Latenz wird von jedem Load-Testing-Tool gemeldet. In k6 meldet die eingebaute http_req_duration-Metrik p50, p95, p99 standardmäßig; fügen Sie thresholds: { http_req_duration: ['p(95)<500'] } hinzu, um den Test zu fail-en, wenn p95 500 ms übersteigt. In JMeter zeigt der Aggregate Report Listener Durchschnitt, Median, p90, p95, p99.

Für Produktions-Latenz instrumentieren Sie den Server mit APM (Datadog, New Relic, Honeycomb) und den Browser mit RUM (Real-User Monitoring). Real-User-Latenz inkludiert den langen Tail langsamer Netzwerke, Mobile-Hardware und gemeinsamer TLS-Terminierung, den synthetische Load Tests nicht sehen.

Führen Sie latenz-fokussierte Tests von LoadFocus gegen 25+ Cloud-Regionen aus, um zu sehen, wie Latenz sich nach Geografie unterscheidet. Eine 50-ms-p95 von us-east-1 ist irrelevant, wenn Ihre Benutzer in Sydney sind und die echte p95 von dort 600 ms ist.

Wenn Ihr Team Latenz-Analyse aufgeschlüsselt nach Endpoint, Region und Tageszeit gegen Produktions-Shape-Last braucht, bietet LoadFocus Load Testing Services, wo Ingenieure die Test-Matrix designen, die Szenarien ausführen und die Latenz-Aufschlüsselung aufschreiben.