Zum Inhalt springen
SDETRole
SDETRole

Glossar · Performance

Durchsatz

Englisch: Throughput

Auch genannt: RPS, TPS, Requests per Second, Anfragen pro Sekunde

Definition

Die Arbeitsmenge, die ein System pro Zeiteinheit erledigt, meist Anfragen oder Transaktionen pro Sekunde, gemessen zusammen mit Latenz und Fehlerrate.

Der Durchsatz (Throughput) gibt an, wie viel Arbeit ein System pro Zeiteinheit erledigt: Anfragen pro Sekunde (RPS) bei einer API, Transaktionen pro Sekunde (TPS) bei einem Zahlungssystem, Nachrichten pro Sekunde bei einem Queue-Consumer. Er misst die Kapazität, während die Latenz misst, wie lange jedes einzelne Arbeitsstück dauert. Um Performance zu beschreiben, brauchen Sie beides, plus die Fehlerrate.

Wie Durchsatz, Latenz und Nebenläufigkeit zusammenhängen

Für ein System im eingeschwungenen Zustand verbindet Littles Gesetz (Little’s Law) die drei Größen:

concurrent requests in flight = throughput × average response time

Example: 200 requests/second × 0.25 seconds = 50 requests in flight

Bei virtuellen Nutzern, die zwischen Aktionen pausieren, verlängert die Denkzeit den Zyklus: Durchsatz ≈ Nutzer ÷ (Antwortzeit + Denkzeit). 100 Nutzer mit 0,5 s Antwortzeit und 4,5 s Denkzeit erzeugen also etwa 20 Anfragen pro Sekunde, nicht 100. Deshalb sagt „Wir haben mit 1.000 Nutzern getestet“ wenig aus, solange Sie nicht auch die Denkzeit und die daraus resultierende Anfragerate nennen.

Wie sich der Durchsatz bei steigender Last verhält

Steigt die Last, wächst der Durchsatz zunächst im Gleichschritt mit. Irgendwann sättigt eine Ressource (CPU, ein Connection-Pool, eine Single-Threaded-Komponente), und der Durchsatz flacht ab, während die Latenz steil ansteigt. Erhöhen Sie weiter, kann der Durchsatz sogar sinken, weil das System seine Kraft für Warteschlangen, Wiederholungen und Timeouts aufwendet. Dieses Plateau zu finden ist das Hauptergebnis eines Stresstests, und es definiert die praktische Kapazität.

Tipps für das Testen

  • Ziele als Rate plus Latenz formulieren. „500 RPS mit p95 unter 300 ms und unter 1 % Fehlern“ ist testbar. „Hält hohen Traffic aus“ ist es nicht.
  • Nur erfolgreiche Arbeit zählen. Ein Server, der 2.000 RPS beantwortet, davon die Hälfte mit 500-Fehlern, leistet keine 2.000 RPS nützlicher Arbeit.
  • Wo möglich Last nach Ankunftsrate erzeugen. Eine feste Anfragerate zeigt direkt, ob das System sie halten kann; ein fester Pool von Nutzern sendet unbemerkt weniger Anfragen, sobald die Antworten langsamer werden.
  • Den Lastgenerator prüfen. Läuft die Maschine, die den Test ausführt, mit 100 % CPU, haben Sie den Durchsatz des Generators gemessen, nicht den des Systems.
  • Auf Rate Limits achten. Ein Gateway, das 429 liefert, deckelt den gemessenen Durchsatz; entscheiden Sie, ob Sie den Limiter testen oder den Dienst dahinter.

Tippen Sie, um SDETRole zu durchsuchen.

Volltextsuche mit Pagefind · läuft in Ihrem Browser Suchseite öffnen →