Was ist Capacity Testing?

Was ist Capacity Testing?

Capacity Testing misst die maximal aufrechterhaltbare Last, die ein System handhaben kann, während es noch seine Service-Level-Objectives (SLOs) erfüllt. Die Ausgabe ist eine saubere Zahl: "Dieses System handhabt X gleichzeitige Benutzer / Y Requests pro Sekunde bei p95-Latenz unter Z." Diese Zahl ist die Grundlage für Infrastruktur-Sizing, Vertrags-Commitments und kundenseitige Kapazitätsangaben.

Capacity Testing vs Breakpoint Testing

Beide rampen Last über erwarteten Peak hinaus. Der Unterschied ist das Stopp-Kriterium:

• Capacity Testing stoppt, wenn SLOs erstmals verletzt werden (p95 überschreitet Ihren Schwellenwert, Fehlerrate übersteigt 0,5%, Durchsatz hört auf, linear zu skalieren). Die Ausgabe ist die höchste Last, die noch SLOs erfüllte.
• Breakpoint Testing fährt nach SLO-Verletzung weiter, um den harten Failure-Punkt zu finden, an dem das System crasht, völlig fehlerhaft wird oder aufhört, Requests anzunehmen. Die Ausgabe ist die absolute Obergrenze, oft weit jenseits akzeptabler Performance.

Capacity = Maximum mit SLO-Compliance. Breakpoint = Maximum vor Totalausfall. Die Lücke zwischen beiden ist Ihre Sicherheitsmarge.

Wann einen Capacity Test ausführen

• Infrastruktur-Sizing. Die Kapazität eines Nodes zu kennen, sagt Ihnen genau, wie viele Nodes Sie für Ziel-Traffic plus Marge brauchen.
• Vertragsverhandlung. Enterprise-Sales fragt "kann das 50.000 Benutzer handhaben?" — Capacity Testing gibt eine ehrliche Antwort.
• SLA-Commitment. Versprechen von 99,9% Verfügbarkeit bei spezifischer Last erfordert Evidenz, dass die Last innerhalb der Kapazität ist.
• Pre-Launch-Validierung. Marketing prognostiziert 5.000 gleichzeitige Benutzer beim Launch. Capacity Testing bestätigt, dass das System es mit Marge handhabt, oder signalisiert, dass 5.000 jenseits der Kapazität sind und skaliert werden muss.
• Autoscaling-Konfiguration. Pro-Pod-Kapazität geteilt durch Ziel-Auslastung gibt Ihnen den Scale-out-Trigger.

Wichtige Capacity-Test-Metriken

1. Maximal aufrechterhaltbare VU-Anzahl oder RPS. Die Hauptausgabe. Das Lastniveau, bei dem SLOs zuletzt erfüllt wurden.
2. Marge zum Breakpoint. Capacity / Breakpoint Ratio. Eine Kapazität bei 80% des Breakpoints ist gesund; Kapazität bei 99% des Breakpoints ist fragil.
3. Ressourcenauslastung bei Kapazität. CPU, Memory, DB-Connections, Thread Pool bei der Kapazitätszahl. Sagt Ihnen, welche Dimension zu skalieren ist.
4. Zeit bei Kapazität. Hält das System die Kapazitätslast für die volle SLO-Dauer (15 min, 1 Stunde, 24 Stunden)? Manche Systeme erreichen eine hohe VU-Anzahl kurz, degradieren aber bei anhaltender Last über die Zeit.

Wie einen Capacity Test ausführen

Gleiche Skripte wie Load Testing, mit einem Step-Ramp, der bei jedem Level lange genug pausiert, um SLO-Compliance zu bestätigen. In JMeter verwenden Sie die Stepping Thread Group, um bei jedem VU-Level 5-15 Minuten zu halten, bevor Sie hochsteigen. In k6 konfigurieren Sie ein mehrstufiges ramping-vus-Szenario mit anhaltenden Halts bei jedem Step.

Definieren Sie Ihren SLO-Schwellenwert zuerst (z.B. "p95-Latenz unter 800 ms, Fehlerrate unter 0,5%"). Die Kapazität ist der höchste Step, bei dem das SLO für die volle Halte-Dauer hielt. Drop einen Step darunter für eine Sicherheitsmarge.

Führen Sie von LoadFocus aus für verteiltes Capacity Testing, wo Load Generators in mehreren Regionen die geo-verteilte Kapazität des Systems testen, nicht nur Single-Region.

Für Capacity Testing, das vorstands-level Kapazitäts-Commitments informiert, bietet LoadFocus Load Testing Services, wo Ingenieure den Test ausführen, die Kapazität mit Infrastruktur-Kontext dokumentieren und einen für Stakeholder geeigneten Bericht produzieren.