Lasttest für Spitzenlast: Shop auf Peaks vorbereiten

Drei Disziplinen werden oft verwechselt, obwohl sie unterschiedliche Fragen beantworten. Das laufende Performance-Monitoring beobachtet den realen Betrieb und schlägt Alarm, wenn Kennzahlen aus dem Rahmen fallen. Das Plugin-Audit sucht im Bestand nach Erweiterungen, die dauerhaft Leistung kosten. Der Lasttest dagegen ist ein einmaliger, geplanter Eingriff vor einem bekannten Ereignis: Er setzt den Shop kontrolliert unter ein Vielfaches der erwarteten Last, um vorab zu wissen, wo die Grenze liegt. Alle drei gehören zusammen, aber nur der Lasttest beantwortet die Kapazitätsfrage, bevor echte Kunden sie stellen.

Die Konsequenz ist eine klare Arbeitsteilung. Monitoring und Audit halten den Alltag stabil; der Lasttest bereitet die Ausnahme vor. In der Performance-Wartung planen wir den Lasttest deshalb als eigenständigen Baustein vor jeder absehbaren Umsatzspitze -- nicht als Reaktion auf einen Vorfall, sondern als Vorsorge, deren Ergebnis eine belastbare Zahl ist: die Last, ab der es eng wird.

Ein Lasttest ist nur so aussagekräftig wie sein Szenario. Ein reiner Dauerbeschuss der Startseite sagt wenig über einen Shop aus, der am Peak-Tag an Suche, Warenkorb und Checkout scheitert. Das Szenario muss den echten Nutzerfluss nachbilden -- inklusive der teuren Schreibpfade, die sich unter Last am ehesten stauen. Die Grundlage liefern die eigenen Daten: die Kurve des Vorjahres-Peaks, die geplante Reichweite der Aktion und ein realistisches Wachstum. Wer die konkreten Ausfallkosten des eigenen Shops kennt, kann den Aufwand für den Test klar gegen das Risiko abwägen.

Über allem steht der Puffer. Die Zielgröße des Tests ist nicht die erwartete Spitze, sondern ein Vielfaches davon. In der Praxis hat sich bewährt, auf das Zwei- bis Dreifache der prognostizierten Last zu testen (Projekterfahrung) -- denn Prognosen irren, virale Effekte lassen sich nicht planen, und eine Reserve über der Erwartung ist der Unterschied zwischen einem knappen und einem entspannten Peak-Tag.

Auf einen zu niedrigen Breaking Point gibt es zwei Antworten, die sich ergänzen: die Last pro Anfrage senken und Kapazität hinzufügen. Das Senken beginnt beim Caching, denn die schnellste Anfrage ist die, die den Applikationsserver gar nicht erst erreicht. Shopware bezeichnet den HTTP-Cache ausdrücklich als Must-have für jedes Produktivsystem (Shopware Documentation) -- ein vollständig gecachter Seitenaufruf kostet einen Bruchteil eines dynamisch berechneten. Erst wenn das Caching ausgereizt ist, lohnt sich zusätzliche Rechenkapazität.

Autoscaling ist wirksam, aber kein Selbstläufer. Neue Instanzen brauchen Zeit zum Hochfahren -- bei einem plötzlichen Lastsprung kann diese Verzögerung selbst zum Engpass werden, weshalb Schwellen bewusst früh greifen sollten. Vor allem skaliert die Datenbank nicht einfach mit: Sie ist der klassische Flaschenhals, der von zusätzlichen Applikationsservern sogar stärker belastet wird. Und auch eingebundene Zahlungs- und Skriptressourcen gehören unter Last geprüft -- wie im Beitrag zu PCI-DSS und Skript-Monitoring der Zahlungsseiten beschrieben, kann ein langsames Drittskript den gesamten Checkout ausbremsen.

Die einzelnen Bausteine greifen zu einem festen Ablauf ineinander: Kapazität aus Daten schätzen, mit Puffer testen, den Breaking Point ermitteln, Caching und Skalierung nachziehen, in einer Generalprobe bestätigen und nach dem Event geordnet zurückbauen. Aus einem riskanten Aktionstag wird so eine planbare Leistung. Genau das ist der Kern unserer Performance-Wartung: Wir bereiten Shopware- und WordPress-Shops proaktiv auf ihre Umsatzspitzen vor. Flankiert von kontinuierlichem Monitoring und einem SLA-Wartungsvertrag mit klaren Reaktionszeiten ist der Peak nicht länger die Stunde der Wahrheit, sondern ein geprobter Ablauf.