Was ist Capacity Testing?

Was ist Capacity Testing?

Beim Capacity Testing ermittelst du die höchste Last, die ein System tragen kann, ohne seine Leistungsziele zu verletzen, etwa ein p95-Antwortzeitlimit oder eine maximale Fehlerrate. Du erhöhst die Last schrittweise und hörst bei der letzten Stufe auf, in der alle Ziele eingehalten wurden. Das Ergebnis ist eine konkrete Zahl, zum Beispiel gleichzeitige Nutzer oder Anfragen pro Sekunde, mit der du Server dimensionierst und Wachstum planst.

So läuft ein Capacity-Test ab

1. Ziele zuerst festlegen. Zum Beispiel: p95-Antwortzeit unter 800 ms und Fehlerrate unter 0,5 %. Das sind deine Service-Level-Ziele (SLOs).
2. In Stufen hochfahren. Beginne unter dem erwarteten Traffic und erhöhe die Last in gleichen Schritten. Halte jede Stufe lange genug, um stabile Werte zu lesen (üblich sind 5 bis 15 Minuten).
3. Auf jeder Stufe alle Ziele prüfen. Die Stufe, in der ein Ziel erstmals verfehlt wird, beendet den Test.
4. Ergebnis ablesen. Die Kapazität ist die letzte Stufe, in der alle Ziele hielten. Betreibe das System darunter, mit Sicherheitsreserve.

Beispiel: Eine Checkout-API hält ihre Ziele bei 300, 400 und 500 virtuellen Nutzern, bei 600 steigt p95 über das Limit. Die Kapazität liegt bei 500 Nutzern. Erwartest du 450 zur Spitze, bleibt kaum Luft, also skaliere vor dem Launch und nicht danach.

Capacity Testing vs. Breakpoint Testing

Beide treiben die Last über die erwartete Spitze hinaus. Der Unterschied liegt im Abbruchkriterium:

• Capacity Testing endet, sobald die Ziele erstmals verletzt werden. Ergebnis ist die höchste Last, die sie noch erfüllte.
• Breakpoint Testing läuft weiter, bis das System hart ausfällt. Ergebnis ist die absolute Obergrenze, meist weit jenseits akzeptabler Leistung.

Die Lücke dazwischen ist deine Sicherheitsreserve. Zum größeren Zusammenhang siehe Skalierbarkeitstests, die fragen, wie sich die Kapazität mit mehr Ressourcen verändert, und den Blog-Vergleich Load Testing vs. Stress Testing.

Wann ein Capacity-Test sinnvoll ist

• Infrastruktur dimensionieren. Die Kapazität eines Knotens zeigt, wie viele Knoten du für den Ziel-Traffic plus Reserve brauchst.
• Vor Launch oder Kampagne. Prüfe, ob der prognostizierte Traffic innerhalb der Kapazität liegt, solange du noch gegensteuern kannst.
• Autoscaling-Regeln. Kapazität pro Instanz geteilt durch die Ziel-Auslastung ergibt einen sinnvollen Scale-out-Trigger.
• Nach größeren Änderungen. Neue Datenbank, neues Framework oder neuer Cache können die Kapazität in beide Richtungen verschieben.

Was du bei der Kapazität festhältst

• Maximale tragbare Nutzer oder Anfragen pro Sekunde. Das Hauptergebnis.
• Abstand zum Breakpoint. Kapazität bei 80 % des Breakpoints ist komfortabel, bei 99 % ist sie fragil.
• Ressourcenverbrauch bei Kapazität. CPU, Speicher, Datenbankverbindungen und Thread-Pools zeigen, was du zuerst skalierst.
• Zeit bei Kapazität. Manche Systeme bestehen einen kurzen Halt und brechen unter Dauerlast ein. Halte die oberste Stufe so lange, wie dein SLO gilt, und nutze für schleichende Lecks einen längeren Soak-Test.

Häufige Fehler

• Keine Ziele definieren, sodass "Kapazität" ein Gefühl statt einer Zahl bleibt.
• Zu schnell stufen. Warteschlangen und Caches brauchen Zeit, kurze Haltezeiten überschätzen die Kapazität.
• Nur einen Endpunkt testen, obwohl echter Traffic gemischt ist. Nutze ein realistisches Szenario.
• Mittelwerte statt Perzentile lesen. Warum der Durchschnitt langsame Anfragen versteckt, steht unter Latenz.
• In einer kleineren Umgebung als der Produktion testen und das Ergebnis nach Gefühl hochrechnen.

Mit LoadFocus umsetzen

Capacity Testing nutzt dieselben Skripte wie Load Testing, nur mit gestufter Rampe. JMeter- und k6-Tests laufen beide aus der Cloud, und LoadFocus Load Testing startet aus 25 Cloud-Regionen, sodass du die Kapazität so testest, wie Nutzer in mehreren Regionen sie erleben. Du kannst Schwellenwerte für p95- und p99-Antwortzeit, maximale Fehlerrate und minimalen Durchsatz setzen. Jeder Lauf erhält ein Bestanden/Nicht-bestanden-Urteil, das in der CI ein Deployment stoppen kann. Der Free-Plan ist auf 10 virtuelle Nutzer begrenzt, bezahlte Pläne erlauben bis zu 20.000 gleichzeitige Nutzer pro Test.

Häufige Fragen

Was ist der Unterschied zwischen Capacity Testing und Load Testing?

Load Testing prüft das Verhalten bei erwarteter Last. Capacity Testing erhöht die Last weiter, um das Maximum zu finden, das das System innerhalb seiner Ziele trägt.

Wie unterscheidet sich Kapazität vom Breakpoint?

Kapazität ist die letzte Laststufe, die deine Ziele noch erfüllte. Der Breakpoint ist der Punkt, an dem das System wirklich ausfällt. Die Kapazität liegt immer darunter, die Lücke ist deine Sicherheitsreserve.

Wie lange sollte jede Stufe gehalten werden?

Lange genug, damit sich die Antwortzeiten einpendeln, üblich sind 5 bis 15 Minuten. Systeme mit Caches, Warteschlangen oder Connection-Pools brauchen längere Haltezeiten.

Welche Metriken bestimmen die Kapazität?

Antwortzeit-Perzentile (p95 oder p99), Fehlerrate und Durchsatz. Die Kapazität ist die höchste Last, bei der alle drei innerhalb deiner Ziele bleiben.

Wie oft sollte ich einen Capacity-Test wiederholen?

Nach wesentlichen Änderungen an Code, Infrastruktur oder Datenmenge und vor erwarteten Traffic-Spitzen. Ein geplanter Lauf erkennt schleichende Verschlechterungen dazwischen.