API-Durchsatz-Kapazitäts-Rechner
Ob eine API die erwartete Last trägt, hängt von Antwortzeit und Parallelität ab, nicht vom Bauchgefühl. Mit der Little'schen Formel ermittelt dieser Rechner aus Ziel-Requests pro Sekunde und durchschnittlicher Antwortzeit, wie viele parallele Worker Du brauchst und wie viel Reserve Dir bei Deiner Konfiguration bleibt.
Dieses Tool ist für Mitglieder
Dieses Premium-Tool schaltest du mit einem kostenlosen Konto frei — zusammen mit allen anderen Profi-Tools und den ganzen Wissen-Artikeln.
100 % kostenlos · keine Kreditkarte · sofort freigeschaltet
Wozu dient der API-Durchsatz-Kapazitäts-Rechner?
Ob eine API die erwartete Last trägt, lässt sich überraschend exakt vorab berechnen – mit dem Little'schen Gesetz. Es besagt, dass der erreichbare Durchsatz vom Verhältnis aus Parallelität (Anzahl gleichzeitig arbeitender Worker) und durchschnittlicher Bearbeitungszeit pro Request abhängt. Ein einzelner Worker schafft bei 80 ms Antwortzeit rechnerisch 12,5 Requests pro Sekunde; mit 24 Workern ergeben sich 300 RPS theoretischer Maximaldurchsatz. Dieser Rechner ermittelt aus deinem Ziel-Durchsatz und der gemessenen Antwortzeit, wie viele Worker du benötigst – inklusive Sicherheitspuffer über eine wählbare Ziel-Auslastung, damit deine Server nicht am Limit fahren. Du siehst die aktuelle Auslastung deiner Konfiguration, ob sie ausreicht oder überlastet ist, wie viele Worker noch fehlen und welches Tagesvolumen an Requests dein Ziel-RPS bedeutet. So planst du Kapazität faktenbasiert statt auf Verdacht.
Beispiele
- 80 ms Antwortzeit: ein Worker schafft
1 / 0,08 = 12,5 RPS. - Ziel 200 RPS bei 80 ms: rechnerisch 16 Worker, mit 70 % Ziel-Auslastung 23 Worker.
- 24 vorhandene Worker ergeben 300 RPS Maximum – bei 200 RPS sind das 66,7 % Auslastung: ausreichend.
- 200 RPS bedeuten
200 × 86.400 = 17,28 Mio.Requests pro Tag.
Häufige Fragen zum API-Durchsatz-Kapazitäts-Rechner
Was ist das Little'sche Gesetz?
Eine Grundgleichung der Warteschlangentheorie: Die Zahl gleichzeitig im System befindlicher Anfragen entspricht dem Durchsatz multipliziert mit der durchschnittlichen Verweildauer. Für APIs heißt das: nötige Worker = Ziel-RPS × Antwortzeit in Sekunden.
Warum sollte ich nicht 100 Prozent Auslastung anpeilen?
Bei voller Auslastung führt schon eine kleine Lastspitze zu Warteschlangen und steigenden Antwortzeiten. Eine Ziel-Auslastung von 60 bis 75 Prozent lässt Puffer für Spitzen, Deployments und ausfallende Instanzen.
Gilt die Rechnung auch für asynchrone oder I/O-lastige APIs?
Die Formel liefert eine solide Obergrenze. Bei stark I/O-gebundenen Diensten kann ein Worker durch asynchrone Verarbeitung mehrere Requests parallel bedienen – dann erhöht sich die effektive Parallelität entsprechend. Für CPU-gebundene Dienste ist die Rechnung am genauesten.
Was zählt als ein Worker?
Eine Verarbeitungseinheit, die jeweils einen Request gleichzeitig bearbeitet – etwa ein Thread, ein Prozess, ein PHP-FPM-Worker oder eine Goroutine. Entscheidend ist die maximale echte Parallelität deiner Anwendung.
