Kapazitätsplanung ist die Frage, wie viel Last ein System verträgt und was passiert, wenn es mehr wird. Sie wird meist zu spät gestellt: nach dem ersten Ausfall. Dabei ist der Aufwand vorher gering und der Erkenntnisgewinn hoch — vor allem, weil das Ergebnis fast nie dort liegt, wo man es vermutet.
Warum Systeme plötzlich umfallen
Unter steigender Last verhalten sich Systeme nicht linear. Bis zu einem bestimmten Punkt steigen die Antwortzeiten kaum. Dann füllt sich eine Warteschlange — Verbindungspool, Thread-Pool, Festplatten-Queue — und ab diesem Moment wächst die Wartezeit exponentiell. Gleichzeitig laufen Timeouts ab, Clients wiederholen ihre Anfragen, und die Wiederholungen erhöhen die Last zusätzlich. Aus einer Überlastung wird so binnen Sekunden ein Totalausfall.
Der Engpass ist fast nie die CPU. In der Praxis sind es Datenbankverbindungen, ein einzelner nicht indizierter Query, ein synchroner Aufruf zu einem externen Dienst oder ein zu klein dimensionierter Verbindungspool.
Die vier Testarten
- Lasttest: Erwartete Spitzenlast über einen realistischen Zeitraum. Beantwortet: Hält das System, was wir versprechen?
- Stresstest: Last so lange steigern, bis das System bricht. Beantwortet: Wo ist die Grenze und wie sieht der Bruch aus?
- Dauertest: Moderate Last über Stunden. Findet Speicherlecks, volllaufende Verbindungspools und wachsende Logdateien — Fehler, die kurze Tests nie zeigen.
- Spike-Test: Sprunghafter Anstieg von null auf Maximum. Bildet ab, was ein viraler Beitrag oder ein Newsletter-Versand tatsächlich auslöst.
Der Stresstest ist der wertvollste, weil er die einzige Zahl liefert, die im Ernstfall zählt: die Grenze. Ohne sie ist jede Skalierungsentscheidung geraten.
Was einen Lasttest wertlos macht
Die meisten Lasttests messen etwas anderes als den Produktivbetrieb. Drei Ursachen dominieren:
- Unrealistische Daten: Eine Testdatenbank mit tausend Datensätzen verhält sich völlig anders als eine mit fünf Millionen. Ohne Datenvolumen testet man Indizes, die es später nicht mehr gibt.
- Zu gleichförmiger Verkehr: Echte Nutzer klicken unterschiedlich, denken zwischendurch nach und rufen ungleich verteilte Seiten auf. Ein Test, der stur denselben Endpunkt anfragt, misst den Cache.
- Testumgebung zu klein oder zu groß: Beides führt zu Zahlen, die sich nicht übertragen lassen. Wenn die Umgebung nicht identisch sein kann, muss der Unterschied wenigstens bekannt und dokumentiert sein.
Headroom statt Punktlandung
Eine sinnvolle Zielgröße ist nicht die maximale Kapazität, sondern der Abstand dazu. Bewährt hat sich, den Normalbetrieb bei etwa der Hälfte der ermittelten Grenze zu fahren. Das klingt großzügig, ist es aber nicht: Der Puffer deckt Lastspitzen, den Ausfall einzelner Instanzen, laufende Deployments und den Umstand ab, dass Systeme mit der Zeit langsamer werden, weil Daten wachsen.
Genau dieser letzte Punkt macht Kapazitätsplanung zu einer wiederkehrenden Aufgabe. Ein System, das heute bei fünfzig Prozent läuft, kann in einem Jahr bei achtzig liegen, ohne dass sich am Verkehr etwas geändert hat.
Was nach dem Test passieren muss
Ein Lasttest ohne Konsequenz ist ein teurer Bericht. Aus den Ergebnissen gehören drei Dinge abgeleitet: die dokumentierte Bruchgrenze als Zahl, ein Alarm bei Annäherung an einen definierten Anteil davon, und ein Verhalten für den Überlastfall. Letzteres ist der am häufigsten übersprungene Punkt — dabei entscheidet er, ob eine Überlastung zu langsamen Antworten oder zu einem Totalausfall führt.
Sinnvolle Schutzmechanismen sind Anfragebegrenzung an der Eingangsschicht, das gezielte Abwerfen unwichtiger Anfragen zugunsten kritischer Pfade und Timeouts mit Circuit Breaker gegen Kaskadeneffekte. Ein System, das unter Überlast langsamer wird, aber antwortet, ist deutlich mehr wert als eines, das erst perfekt läuft und dann gar nicht.
Wann sich der Aufwand lohnt
Nicht jedes Projekt braucht eine ausgebaute Lasttest-Strecke. Sinnvoll wird sie, sobald ein absehbares Ereignis mit Lastspitze bevorsteht — Kampagne, Saison, Produktstart, Medienauftritt —, sobald Ausfallzeiten direkt Umsatz kosten, oder sobald ein Systemwechsel ansteht und Vergleichszahlen fehlen. In diesen Fällen ist ein Tag Testarbeit die günstigste Versicherung im gesamten Projekt.
Die Zahlen, die zählen
Ein Durchschnittswert für Antwortzeiten ist praktisch wertlos, weil er die Ausreißer verdeckt, die Nutzer tatsächlich erleben. Aussagekräftig sind Perzentile: Wie schnell ist die Antwort für die langsamsten fünf Prozent der Anfragen? Wenn der Durchschnitt bei zweihundert Millisekunden liegt, das schlechteste Prozent aber bei acht Sekunden, hat ein relevanter Teil der Nutzer den Vorgang längst abgebrochen — im Durchschnitt sichtbar wird das nie.
Ebenso wichtig ist die Fehlerrate unter Last. Ein System, das unter Spitzenlast schnell antwortet, aber jede zwanzigste Anfrage verwirft, ist nicht schnell, sondern kaputt. Beide Kennzahlen gehören zusammen betrachtet, sonst optimiert man an der falschen Stelle.
Kosten sind Teil der Rechnung
In Cloud-Umgebungen ist Kapazität kaufbar — das verführt dazu, Engpässe mit Hardware zuzuschütten statt sie zu beheben. Kurzfristig funktioniert das und ist manchmal die richtige Entscheidung. Dauerhaft wird es teuer, weil die Kosten linear mit der Last steigen, während eine behobene Ursache einmalig kostet. Ein einziger fehlender Index kann den Unterschied zwischen einer und sechs Instanzen ausmachen. Die Frage bei jedem Skalierungsschritt sollte deshalb lauten, ob gerade Kapazität oder Ineffizienz bezahlt wird.