Durchsatz (Throughput)

Was ist Durchsatz?

Der Durchsatz, englisch Throughput, beantwortet eine einfache Frage: Wie viel Arbeit erledigt das System pro Zeiteinheit? Bei einer Web-API sind das meist Requests pro Sekunde (RPS), bei einem Zahlungssystem Transaktionen pro Minute, bei einem Kafka-Consumer Nachrichten pro Sekunde, bei Festplatte oder Netzwerk Bytes pro Sekunde. Der Durchsatz entspricht dem Signal Traffic der Golden Signals und der Rate in der RED-Methode (Rate, Errors, Duration).

Durchsatz ist nicht dasselbe wie Last. Last ist, was ankommt; Durchsatz ist, was abgeschlossen wird. In einem gesunden System sind beide gleich. Bei Überlast stauen sich Anfragen in Warteschlangen, der Durchsatz stagniert oder sinkt sogar, und die Latenz steigt.

Durchsatz, Latenz und Little's Law

Durchsatz und Latenz hängen zusammen. Little's Law aus der Warteschlangentheorie besagt, dass in einem stabilen System die durchschnittliche Zahl gleichzeitig bearbeiteter Requests gleich der Ankunftsrate mal der durchschnittlichen Verweildauer ist:

L = λ × W
Parallelität = Durchsatz × durchschnittliche Latenz

Ein Beispiel zur Veranschaulichung: Ein Service verarbeitet 200 Requests pro Sekunde bei durchschnittlich 250 ms Latenz, also sind im Mittel 50 Requests gleichzeitig in Arbeit. Verdoppelt sich die Latenz bei gleichem Durchsatz auf 500 ms, verdoppelt sich auch die Parallelität auf 100. Hat der Service einen Pool von 64 Worker-Threads oder Datenbankverbindungen, beginnen Requests nun zu warten, was die Latenz weiter erhöht. Diese Rückkopplung erklärt, warum Systeme oft schlagartig statt allmählich ausfallen.

Nähert sich die Auslastung der Kapazitätsgrenze, steigt die Latenz durch Warteschlangen steil an, obwohl der Durchsatz kaum noch zunimmt. Der sinnvolle Betriebsbereich liegt daher deutlich unter dem theoretischen Maximaldurchsatz, typischerweise dort, wo die Tail-Latenz noch flach verläuft.

So messen Sie Durchsatz

• Request-basierte Services: Zählen Sie abgeschlossene Requests und bilden Sie die Rate. Mit OpenTelemetry enthält das Histogramm http.server.request.duration bereits einen Zähler, Durchsatz und Latenz stammen also aus derselben Metrik.
• Messaging: Erfassen Sie produzierte und konsumierte Nachrichten pro Sekunde sowie den Consumer Lag. Ein Consumer, dessen Durchsatz unter der Produktionsrate liegt, fällt zurück.
• Batch- und Datenpipelines: Messen Sie verarbeitete Datensätze oder Bytes pro Sekunde und die Zeit bis zum Abschluss.
• Infrastruktur: Lese- und Schreib-Bytes pro Sekunde, IOPS und Netzwerk-Bytes pro Sekunde je Interface.

In PromQL sieht der Durchsatz pro Service aus einem nach Prometheus exportierten OpenTelemetry-Histogramm so aus:

sum by (job) (rate(http_server_request_duration_seconds_count[5m]))

Die OTLP-Übersetzung von Prometheus bildet das Resource-Attribut service.name auf das Label job ab, daher die Gruppierung. Teilen Sie den Durchsatz immer nach aussagekräftigen Dimensionen wie Route, Statusklasse und Region auf. Eine unauffällige Gesamt-RPS kann einen Endpunkt verbergen, der auf null gefallen ist.

Warum Durchsatz wichtig ist

• Ausfälle erkennen: Ein plötzlicher Einbruch des Durchsatzes zeigt oft ein Problem, das Fehlermetriken übersehen, etwa Clients, die den Service gar nicht mehr erreichen.
• Kontext für andere Signale: Eine Fehlerrate von 5 Prozent bedeutet bei 10 RPS etwas anderes als bei 10.000 RPS. Quoten brauchen den Nenner.
• Kapazitätsplanung: Durchsatztrends über Monate zeigen zusammen mit dem Ressourcenbedarf pro Request, wann Sie skalieren müssen.
• Geschäftssicht: Bestellungen, Registrierungen oder Zahlungen pro Minute sind Durchsatzkennzahlen, die auch die Geschäftsleitung direkt versteht.

Durchsatz entlang einer Aufrufkette

In verteilten Systemen löst ein Nutzer-Request oft viele interne Aufrufe aus. Ein Checkout-Request ruft etwa Inventar, Preisberechnung und Zahlung auf, und jeder dieser Services fragt eine Datenbank ab. Der interne Durchsatz kann daher ein Vielfaches des Durchsatzes am Edge betragen, und das Verhältnis beider Werte, oft Fan-out genannt, verdient Aufmerksamkeit. Verdoppeln sich die internen Aufrufe pro Edge-Request nach einem Deployment plötzlich, haben Sie womöglich eine N+1-Abfrage oder eine Retry-Schleife eingeführt, obwohl sich der Nutzer-Traffic überhaupt nicht verändert hat. Solche Muster fallen in Traces sofort auf.

Best Practices

1. Auf unerwartete Veränderungen alarmieren, nicht auf feste Schwellwerte. Traffic folgt Tages- und Wochenmustern, vergleichen Sie daher mit einer Baseline oder demselben Zeitpunkt der Vorwoche.
2. Durchsatz erfolgreicher Arbeit getrennt von allen Requests messen, damit schnelle Fehler nicht wie gesunder Traffic aussehen.
3. Mit Lasttests den Knickpunkt finden. Erhöhen Sie die Last schrittweise und notieren Sie, ab wann die p99-Latenz nach oben abknickt. Das ist Ihre praktische Kapazität.
4. Auslastung neben dem Durchsatz beobachten: Thread-Pools, Connection-Pools, CPU und Queue-Tiefe zeigen, wie nah Sie an der Grenze sind.

Typische Fehler

• Durchschnittlichen Durchsatz über einen ganzen Tag berichten und damit die für die Kapazität entscheidenden Spitzen verbergen.
• Retries als Durchsatz zählen, was die nützliche Arbeit während eines Incidents überschätzt.
• Bandbreite (theoretische Kapazität einer Verbindung) mit Durchsatz (tatsächlich übertragene Menge) verwechseln.
• Einen Durchsatzeinbruch ignorieren, weil Latenz und Fehler unauffällig aussehen.

Wie Obseria hilft

Obseria leitet den Durchsatz pro Service, Endpunkt und Abhängigkeit automatisch aus Traces und OpenTelemetry-Metriken ab und zeigt ihn neben Latenz und Fehlern in der Application Observability. Obseria Intelligence lernt saisonale Traffic-Muster und meldet unerwartete Einbrüche oder Spitzen über die Anomalieerkennung. Mit Business Observability verfolgen Sie zudem geschäftlichen Durchsatz wie Bestellungen pro Minute neben technischen Signalen.