Die Spitzenzeit im Onlinehandel steht seit Monaten im Kalender: die Herbst-Aktionstage der großen Marktplätze Mitte Oktober, der Black Friday am 27. November 2026, der Cyber Monday am 30. November und danach das Weihnachtsgeschäft bis in die letzte Lieferwoche. Trotzdem geraten Shops jedes Jahr genau an diesen Tagen ins Straucheln. Am Black Friday 2024 lag der Traffic rund doppelt so hoch wie an einem normalen Oktobertag (Queue-it), und über die Kundenbasis des Fulfillment-Dienstleisters Stord stieg das maximale Tagesbestellvolumen im selben Aktionswochenende um 252 Prozent (Stord). Wer erst am Aktionstag bemerkt, dass die Datenbank bei einigen Tausend gleichzeitigen Sitzungen blockiert, hat keine Zeit mehr zum Nachdenken. Dieser Beitrag zeigt, wie Sie ein realistisches Lastprofil ableiten, einen abgestuften Lasttest fahren, Schwellwerte festlegen und daraus einen Notfallplan bauen, der auch trägt, wenn die Zahlen aus dem Rahmen laufen.
Warum die Spitzenzeit planbar ist - und trotzdem überrascht
Anders als ein Hardwaredefekt im Juli ist die Spitzenzeit kein Zufallsereignis. Die Termine stehen fest, die Kampagnen sind budgetiert, die Ware ist bestellt. Das Vorbereitungsfenster für die technische Seite liegt entsprechend zwischen Juli und September - also lange bevor die ersten Werbemittel ausgespielt werden. Wie viel an diesen Wochen hängt, zeigt das Volumen: Im Weihnachtsgeschäft 2025 setzten Onlinehändler in den USA 257,8 Milliarden US-Dollar um, ein Plus von 6,8 Prozent gegenüber dem Vorjahr (Adobe Analytics). Der europäische Markt folgt derselben Saisonlogik, auch wenn die absoluten Zahlen kleiner ausfallen.
Überraschend ist deshalb selten der Termin, sondern die Form der Kurve. Der Umsatz verteilt sich nicht gleichmäßig über 24 Stunden: Ein Newsletter, ein Countdown oder ein Kampagnenstart um Mitternacht schiebt einen erheblichen Teil der Tagesnachfrage in ein Fenster von wenigen Minuten. Am Black Friday 2024 legte der Traffic gegenüber dem Vorjahr zusätzlich um 5,3 Prozent zu (Queue-it). Entscheidend für die Technik ist nicht der Tagesdurchschnitt, sondern die Minute mit der höchsten Gleichzeitigkeit. Wer die Infrastruktur darauf elastisch auslegen will, findet die Grundlagen im Beitrag zum Auto-Scaling bei Traffic-Spitzen. Dieser Text setzt eine Ebene davor an: bei der Messung, die überhaupt erst sagt, wie viel Kapazität gebraucht wird.
Die meisten Shops kennen ihren Umsatzplan für die Spitzenzeit auf den Euro genau - aber nicht die Zahl gleichzeitiger Sitzungen, ab der die Antwortzeiten kippen. Genau diese Lücke schließt ein Lasttest: Er ersetzt die Annahme durch eine Messung. Und er ist die Voraussetzung für einen belastbaren Notfallplan, denn ohne bekannte Grenze lässt sich keine Schwelle definieren.
Was ein Ausfall in der Spitzenzeit kostet
Im Jahr 2024 kostete eine Minute ungeplanter Ausfallzeit in Organisationen ab 1.000 Beschäftigten im Mittel rund 14.056 US-Dollar (BigPanda/EMA). Für 90 Prozent der mittleren und großen Unternehmen liegen die Kosten einer einzigen Ausfallstunde über 300.000 US-Dollar (Information Technology Intelligence Consulting). Solche Durchschnitte lassen sich nicht eins zu eins auf einen mittelständischen Shop übertragen - die Rechenlogik dahinter aber schon. Der eigene Wert ergibt sich aus dem geplanten Umsatz der Spitzenstunde geteilt durch 60, multipliziert mit der erwarteten Ausfalldauer, zuzüglich des in diesem Zeitfenster verbrannten Werbebudgets und des Mehraufwands im Kundenservice.
Der teurere Teil der Rechnung steht allerdings nicht in der Tagesauswertung. 64 Prozent der Kundinnen und Kunden vertrauen einem Shop nach einem Absturz weniger (Queue-it), und ein erheblicher Teil kehrt nach einer schlechten Erfahrung durch Ausfall oder Langsamkeit nicht mehr zurück. Ein Aktionstag zieht überdurchschnittlich viele Erstbesucher an - Menschen ohne Bindung an die Marke, die bei einer Fehlermeldung schlicht weiterziehen. Der Schaden wirkt damit weit über den Tag hinaus. Ein laufendes Shop-Monitoring für Verfügbarkeit und Performance macht solche Einbrüche wenigstens sichtbar, bevor Kundinnen und Kunden sie melden.
Erstens der entgangene Umsatz der betroffenen Minuten, zweitens das Werbebudget, das in diesem Fenster auf eine nicht erreichbare Seite geleitet wurde, drittens der Mehraufwand in Service und Technik, viertens der Vertrauensverlust bei Erstbesuchern. Die ersten drei Posten lassen sich am Folgetag beziffern, der vierte wirkt über Monate. Schon die Durchschnittswerte zeigen die Größenordnung: rund 14.056 US-Dollar je Ausfallminute in Organisationen ab 1.000 Beschäftigten (BigPanda/EMA).
Das Lastprofil: die Grundlage jedes belastbaren Tests
Vor dem ersten Testlauf steht die Frage, wogegen überhaupt getestet wird. Ein Lasttest mit frei gewählten Nutzerzahlen erzeugt hübsche Diagramme und keine Erkenntnis. Belastbar wird er erst, wenn das Lastprofil aus echten Daten abgeleitet ist. Diese Datenquellen liefern die Grundlage:
- Webanalyse des Vorjahres: Sitzungen, Seitenaufrufe und Bestellungen im Minutenraster für die Aktionstage - nicht als Tagessumme, sondern als Verlauf.
- Serverprotokolle: Anfragen pro Sekunde je Seitentyp. Kategorie-, Produkt- und Checkout-Seiten verhalten sich technisch völlig unterschiedlich.
- Kampagnenplan: Versandzeitpunkte für Newsletter, geplante Countdowns, Startzeiten von Rabattaktionen. Jeder dieser Termine erzeugt eine eigene Spitze.
- Sortimentsdaten: Aktionsartikel mit vielen Varianten oder aufwendigen Filtern belasten Datenbank und Suchindex stärker als der Rest des Katalogs.
- Externe Abhängigkeiten: Zahlungsanbieter, Versanddienstleister und Warenwirtschaft haben eigene Grenzen, die im Test mitgedacht werden sollten.
- Botanteil: Preisvergleiche und Crawler intensivieren ihre Zugriffe in der Aktionswoche und gehören ins Lastprofil, auch wenn sie keinen Umsatz bringen.
Aus diesen Werten entsteht ein Planwert je Kennzahl. Praktisch bewährt hat sich ein zweistufiges Vorgehen: erst den Messwert eines normalen Tages nehmen, dann den Spitzenfaktor daraufrechnen. Als Orientierung für den Faktor dient die 2024 beobachtete Verdopplung des Spitzentag-Traffics gegenüber einem normalen Oktobertag (Queue-it) und der Anstieg des maximalen Tagesbestellvolumens um 252 Prozent im selben Jahr (Stord). Die folgende Tabelle ist ein Rechenbeispiel; die Spalte mit den Messwerten stammt in Ihrem Fall aus der eigenen Auswertung.
| Kennzahl | Normaltag (Messung) | Spitzentag (Planwert) | Herleitung |
|---|---|---|---|
| Seitenaufrufe pro Minute | 1.200 | 2.400 | Faktor 2 wie am Spitzentag 2024 beobachtet (Queue-it) |
| Gleichzeitige Sitzungen | 450 | 900 | gleicher Faktor auf die Sitzungen angewandt |
| Bestellungen pro Minute | 8 | 28 | Zuwachs 252 Prozent am Spitzentag 2024 (Stord) |
| Suchanfragen pro Minute | 300 | 750 | überproportional, weil Aktionsware gesucht wird |
| Zielwert für den Lasttest | - | 3.600 Seitenaufrufe | Planwert plus 50 Prozent Sicherheitsreserve |
Den Lasttest aufsetzen: Umgebung, Szenarien, Stufen
Ein Lasttest ist nur so aussagekräftig wie die Umgebung, in der er läuft. Getestet wird gegen eine produktionsnahe Kopie: gleiche Shop-Version, gleiche Erweiterungen, vergleichbare Datenmenge im Katalog und dieselbe Cache-Konfiguration. Ein System mit tausend Testartikeln verhält sich anders als eines mit einem gewachsenen Sortiment. Im Hosting und der laufenden Wartung lässt sich eine solche Kopie mit vertretbarem Aufwand vorhalten und für jeden Testlauf auf denselben Ausgangszustand zurücksetzen. Nur so sind zwei Läufe überhaupt vergleichbar.
Inhaltlich bildet der Test den realen Weg der Kundschaft ab, nicht nur die Startseite. Ein brauchbares Szenario mischt Einstiegsseiten, Kategorieaufrufe mit Filtern, Produktdetailseiten, Suchanfragen, Warenkorbaktionen und einen Anteil abgeschlossener Bestellungen. Der Checkout ist dabei der aufwendigste Pfad und zugleich der, der am Spitzentag zählt. Anschließend wird die Last in Stufen hochgefahren, damit sichtbar wird, an welcher Stelle die Kurve kippt:
- Aufwärmen: Fünf Minuten mit geringer Last, damit Caches und Verbindungen einen realistischen Zustand erreichen.
- Stufen hochfahren: Die Nutzerzahl in festen Schritten steigern und jede Stufe mindestens fünf Minuten halten - kurze Spitzen verdecken langsam wachsende Probleme.
- Planwert halten: Den ermittelten Spitzentag-Planwert eine halbe Stunde lang stabil fahren. Erst diese Dauerlast zeigt Speicherlecks und volllaufende Warteschlangen.
- Über den Planwert hinaus: Weiter steigern, bis eine Schwelle reißt. Der so gefundene Knickpunkt ist die eigentliche Kapazitätsgrenze.
- Abklingen: Die Last wieder senken und prüfen, ob sich das System selbst erholt oder ein Neustart nötig wird.
- Nachbereiten: Protokolle, Datenbankstatistiken und Warteschlangen auswerten, solange die Messdaten frisch sind.
Ein Lasttest gegen das Livesystem erzeugt echte Bestellungen, echte Zahlungsvorgänge, echte Bestätigungsmails und echte Einträge in der Warenwirtschaft. Zusätzlich können Schutzmechanismen die Testlast als Angriff werten und Adressen sperren. Wenn eine Kopie technisch nicht darstellbar ist, gehört der Test in ein eng begrenztes Zeitfenster mit abgeschalteter Bestellstrecke, gesperrtem Mailversand und vorab informierten Dienstleistern - und mit einer Person, die den Lauf jederzeit abbrechen kann.
# Stufenplan für den Peak-Season-Lasttest
szenario: Spitzentag-Simulation
umgebung: produktionsnahe Kopie, gleiche Version und Datenmenge
messpunkte:
- kategorieseite mit Filter
- produktdetailseite
- suche
- warenkorb
- checkout-abschluss
verteilung:
kategorie: 40
produkt: 30
suche: 15
warenkorb: 10
checkout: 5
stufen:
- nutzer: 500
dauer: 5m
- nutzer: 1000
dauer: 5m
- nutzer: 2000
dauer: 5m
- nutzer: 4000
dauer: 5m
- nutzer: 6000
dauer: 30m # Planwert halten
- nutzer: 8000
dauer: 5m
- nutzer: 10000
dauer: 5m
abbruch:
antwortzeit_p95: 2.5s
fehlerrate: 1%
checkout_fehler: 0.5%Wichtig ist die Wiederholbarkeit. Jeder Lauf sollte zur gleichen Tageszeit, mit demselben Datenstand und demselben Szenario starten. Nur dann sagt ein zweiter Lauf nach einem Umbau tatsächlich etwas über die Wirkung dieses Umbaus aus. Ein einzelner Test liefert eine Momentaufnahme, eine Testreihe liefert eine Kurve - und die Kurve ist das, was in der Planung zählt.
Schwellwerte festlegen: Zielwert, Warnschwelle, Notbremse
Ein Lasttest ohne vorher festgelegte Schwellwerte endet in einer Diskussion darüber, ob 1,8 Sekunden noch akzeptabel sind. Diese Diskussion gehört vor den Test, nicht danach. Drei Werte reichen aus, und sie sollten schriftlich festgehalten und mit dem Fachbereich abgestimmt sein. Dieselben Werte bilden später die Auslöser im Notfallplan - deshalb lohnt es sich, sie so zu wählen, dass zu jedem eine konkrete Handlung gehört.
Zielwert
Der Wert, den der Shop unter Planlast halten soll - etwa 0,8 Sekunden für die Serverantwort im 95. Perzentil. Er orientiert sich an dem, was Nutzerinnen und Nutzer erfahrungsgemäß als zügig empfinden, und passt zu den Anforderungen der Core Web Vitals.
Warnschwelle
Der Punkt, an dem der Betrieb noch läuft, die Reserve aber schmilzt - etwa 1,5 Sekunden. Hier greifen vorbereitete Entlastungen, bevor Kundinnen und Kunden etwas merken. Die Warnschwelle löst Handeln aus, nicht nur eine Benachrichtigung.
Notbremse
Die Grenze, ab der eine kontrollierte Reduktion besser ist als ein unkontrollierter Ausfall - etwa 2,5 Sekunden oder eine Fehlerrate über einem Prozent. Ein Warteraum vor dem Shop ist unangenehm, ein Zeitüberschreitungsfehler im Checkout ist teurer.
Messpunkt und Perzentil
Gemessen wird nicht der Mittelwert, sondern das 95. Perzentil, und zwar getrennt je Seitentyp. Ein guter Durchschnitt verdeckt regelmäßig, dass der Checkout bereits im Sekundenbereich hängt, während die Startseite aus dem Cache kommt.
Neben der Antwortzeit gehören zwei weitere Kennzahlen in das Schwellenwerk: die Fehlerrate und die Sättigung der begrenzten Ressourcen. Zur Sättigung zählen belegte Datenbankverbindungen, Auslastung der Prozessorkerne, freier Arbeitsspeicher und die Länge der Warteschlangen. Diese Werte steigen typischerweise, bevor die Antwortzeit sichtbar reagiert - sie sind das Frühwarnsystem. Wie sich die reine Auslieferungsgeschwindigkeit systematisch verbessern lässt, ist Thema der PageSpeed-Optimierung; im Lasttest geht es um die Frage, wie lange diese Geschwindigkeit unter Druck hält.
Engpässe, die ein Lasttest sichtbar macht
In der Praxis wiederholen sich die Befunde. Es sind selten exotische Fehler, die einen Shop am Spitzentag ausbremsen, sondern eine Handvoll bekannter Muster, die im Alltagsbetrieb schlicht nicht auffallen, weil die Last dafür zu gering ist:
- Datenbankverbindungen: Das Verbindungslimit ist erreicht, bevor Prozessor oder Arbeitsspeicher an ihre Grenze kommen. Anfragen warten dann auf einen freien Platz statt auf Rechenzeit.
- Einbrechende Cache-Trefferquote: Personalisierte Elemente, Kundengruppenpreise oder Warenkorb-Bausteine umgehen den Seiten-Cache. Am Aktionstag mit vielen angemeldeten Kunden sinkt die Trefferquote genau dann, wenn sie gebraucht wird - ein Fall für sauber ausgelegtes Redis-Caching in Shopware.
- Stauende Hintergrundprozesse: Bestellbestätigungen, Lagerabgleiche und Indexaktualisierungen laufen über Warteschlangen. Reichen die Worker im Produktivbetrieb nicht aus, wächst der Rückstand still, bis Bestätigungen Stunden zu spät ankommen.
- Suchindex und Filter: Aufwendige Filterkombinationen auf Aktionskategorien erzeugen deutlich mehr Last als eine einfache Produktseite und treffen den Index besonders hart.
- Bilder und Medien: Unkomprimierte Produktbilder in Aktionsbannern vervielfachen das Übertragungsvolumen genau dann, wenn die Leitung ohnehin gefüllt ist.
- Externe Schnittstellen: Zahlungsanbieter, Versanddienstleister und Warenwirtschaft haben eigene Grenzen. Besonders komplexe Fälle wie der Speditionsversand von Sperrgut mit Frachtberechnung im Checkout verdienen im Test eigene Aufmerksamkeit.
- Mailversand: Ein Ansturm auf die Bestellstrecke erzeugt einen Ansturm auf den Mailausgang. Wie sich die Bestellbestätigung als Umsatzkanal aufstellen lässt, ohne den Versand am Spitzentag zu überfordern, ist eine eigene Betrachtung wert.
- Protokolle und Speicherplatz: Ausführliche Protokollierung unter Last füllt Datenträger schneller als gedacht. Ein volles Dateisystem legt einen Shop ebenso zuverlässig lahm wie eine überlastete Datenbank.
| Engpass | Symptom im Lasttest | Gegenmaßnahme |
|---|---|---|
| Datenbankverbindungen | Antwortzeit springt sprunghaft, Prozessorlast bleibt niedrig | Verbindungspool erhöhen, Abfragen entlasten |
| Cache-Trefferquote | Antwortzeit steigt mit Zahl angemeldeter Nutzer | Personalisierung aus dem Seiten-Cache lösen |
| Warteschlangen | Rückstand wächst, Bestätigungen verzögern sich | Worker aufstocken, unkritische Jobs verschieben |
| Suchindex | Filterseiten deutlich langsamer als Produktseiten | Facetten reduzieren, Ergebnisse zwischenspeichern |
| Übertragungsvolumen | Ladezeit steigt, Serverlast bleibt gleich | Bilder vorab optimieren, Auslieferung verteilen |
| Externe Schnittstellen | Zeitüberschreitungen im Checkout | Zeitlimits setzen, Ausweichweg definieren |
Der Notfallplan: Eskalationsstufen statt Improvisation
Der Lasttest sagt, wann es eng wird. Der Notfallplan sagt, was dann passiert. Beides gehört zusammen, denn ein Schwellwert ohne hinterlegte Handlung ist nur eine Zahl auf einem Bildschirm. Ein brauchbarer Plan passt auf zwei Seiten, ist ausgedruckt verfügbar und benennt für jede Stufe eine Handlung, eine verantwortliche Rolle und ein Zeitfenster. Diese Struktur hat sich bewährt:
- Rollen und Erreichbarkeit: Wer entscheidet, wer setzt um, wer informiert die Kundschaft? Mit Namen, Telefonnummern und einer benannten Vertretung je Rolle.
- Stufe 1 - Beobachten: Der Zielwert wird gehalten. Die Bereitschaft schaut auf ein festgelegtes Kennzahlenbild, ohne einzugreifen.
- Stufe 2 - Lastventile öffnen: Ab der Warnschwelle werden vorbereitete Entlastungen aktiviert: unkritische Hintergrundjobs pausieren, Empfehlungsmodule und aufwendige Filter abschalten, Bilder in kleinerer Auflösung ausliefern, Protokollierung reduzieren.
- Stufe 3 - Notbremse: Ab der Notbremsschwelle greift die kontrollierte Reduktion: ein Warteraum vor dem Shop, ein Sparmodus mit vereinfachten Seiten, notfalls das vorübergehende Abschalten einzelner Funktionen zugunsten der Bestellstrecke.
- Kommunikation: Eine vorbereitete Statusmeldung, ein abgestimmter Text für den Kundenservice und eine kurze Ansage im Shop. Schweigen kostet mehr Vertrauen als eine ehrliche Wartungsmeldung.
- Rückweg: Für jede Maßnahme steht fest, wie sie zurückgenommen wird. Ein Sparmodus, den nach dem Aktionstag niemand abschaltet, wird selbst zum Problem.
- Wiederanlauf: Für den schwersten Fall gilt der Ablauf aus dem Notfallplan für Backup und Wiederherstellung - mit geprüften Sicherungen und geübtem Wiederanlauf.
- Protokoll: Wer wann was getan hat, wird mitgeschrieben. Das Protokoll ist die Grundlage der Nachbetrachtung und der Planung für das Folgejahr.
Wenn nur eine Person die Zugänge kennt, die Schalter findet und weiß, in welcher Reihenfolge etwas abgeschaltet wird, ist der Plan an einem Sonntagabend im November wertlos. Zugangsdaten gehören in eine geteilte, abgesicherte Ablage, die Handlungsanweisungen in ein Dokument, das auch ohne den eigenen Shop erreichbar ist. Dass ein Notfallplan fehlt, liegt selten am fehlenden Willen - sondern daran, dass niemand die Verantwortung übernommen hat, ihn aufzuschreiben.
Der Begriff Lastventil verdient eine Erläuterung, weil er in der Planung oft zu abstrakt bleibt. Gemeint sind Funktionen, die im Normalbetrieb nützlich, unter Volllast aber verzichtbar sind: Produktempfehlungen, Bewertungssterne aus einer externen Quelle, Live-Lagerbestände auf Übersichtsseiten, aufwendige Facettenfilter, animierte Banner. Jede einzelne dieser Funktionen kostet Rechenzeit oder eine externe Anfrage. Wenn sie sich über einen Schalter deaktivieren lassen und dieser Schalter vorab getestet wurde, gewinnt der Shop im Ernstfall Reserve, ohne dass die Bestellstrecke angetastet wird.
Der Betriebskalender bis zum Spitzentag
Lasttest und Notfallplan sind keine Aufgaben für eine Woche, sondern eine Abfolge über mehrere Monate. Der Grund ist einfach: Zwischen erstem Test, Umbau und Nachtest liegen Umsetzungszeiten, und ein Umbau ohne Nachtest ist eine Wette. Die folgende Abfolge lässt sich auf die meisten Shops übertragen:
| Zeitraum | Aufgabe | Ergebnis |
|---|---|---|
| Juli | Lastprofil aus Vorjahresdaten ableiten, Planwerte abstimmen | Zielzahlen für den Test stehen |
| August | Testumgebung aufbauen, erster Stufentest | Kapazitätsgrenze und Engpassliste |
| September | Engpässe abarbeiten, zweiter Testlauf | gemessene Verbesserung statt Vermutung |
| Oktober | Notfallplan schreiben, Lastventile testen, Probelauf | geübte Abläufe, benannte Rollen |
| November | Änderungsstopp, Bereitschaft besetzen, Kennzahlenbild scharf stellen | stabiler Zustand am Spitzentag |
| Dezember bis Januar | Auswertung, Protokoll, Planung für das Folgejahr | belastbare Grundlage für die nächste Saison |
Ein Punkt verdient besondere Beachtung: der Änderungsstopp. Ab etwa zwei Wochen vor dem ersten Aktionstag gehen keine funktionalen Änderungen mehr live - keine neue Erweiterung, kein Umbau der Kategoriestruktur, kein Wechsel des Zahlungsanbieters. Sicherheitsaktualisierungen bleiben davon ausgenommen, alles andere wartet bis Januar. Wer in dieser Zeit einen Relaunch plant, verschiebt ihn besser: Selbst ein sauberes Redirect-Konzept für den Relaunch braucht Beobachtungszeit, die in der Spitzenzeit niemand hat. Auch die Auslieferung selbst sollte vor dem Stopp stehen - eine tragfähige CDN-Strategie für Online-Shops gehört in den September, nicht in die Aktionswoche. Wie stark die Saison insgesamt wiegt, zeigt das Weihnachtsvolumen von 257,8 Milliarden US-Dollar allein im US-Onlinehandel (Adobe Analytics).
Kapazität planen statt hoffen
Die Spitzenzeit belohnt Vorbereitung und bestraft Annahmen. Ein Shop, der seine Kapazitätsgrenze kennt, seine Schwellwerte schriftlich festgelegt hat und für jede Schwelle eine geübte Handlung bereithält, geht mit deutlich weniger Risiko in den Aktionstag als einer, der auf ein ruhiges Wochenende hofft. Der Aufwand dafür ist überschaubar und fällt in ein Zeitfenster, in dem im Handel ohnehin geplant wird. Entscheidend ist, dass Messung, Schwellwert und Handlung zusammengehören - eine Zahl ohne Konsequenz hilft am Spitzentag niemandem.
Lastprofil und Stufentest
Wir leiten aus Ihren Vorjahresdaten ein realistisches Lastprofil ab und fahren den Stufentest gegen eine produktionsnahe Kopie - mit dokumentierter Kapazitätsgrenze als Ergebnis.
Schwellwerte und Alarmierung
Zielwert, Warnschwelle und Notbremse werden festgelegt, im Monitoring hinterlegt und mit einer Meldekette verbunden, damit die richtige Person zur richtigen Zeit informiert ist.
Notfallplan und Probelauf
Lastventile werden eingebaut, dokumentiert und vorab getestet. Der Plan wird einmal geprobt, denn ein ungeübter Ablauf verliert im Ernstfall wertvolle Minuten - bei rund 14.056 US-Dollar Ausfallkosten je Minute in größeren Organisationen (BigPanda/EMA) ein lohnender Aufwand.
Betrieb über die Spitzenzeit
Im Hosting und der Wartung begleiten wir die Aktionswochen mit Bereitschaft und Kennzahlenbild - passend dazu, dass ein erheblicher Teil der Kundschaft nach einer schlechten Erfahrung nicht mehr zurückkehrt.
Ob Shopware, WooCommerce oder eine individuell entwickelte Lösung: Der Ablauf bleibt derselbe - messen, Grenze finden, Schwellen setzen, Handlungen üben. Für Shopware-Projekte bringt unsere Arbeit als Shopware-Agentur die Kenntnis mit, an welchen Stellen der Katalog, der Cache und die Warteschlangen unter Last typischerweise nachgeben. Sprechen Sie unser Team an, wenn Sie Lasttest und Notfallplan für die kommende Spitzenzeit planbar aufsetzen möchten - das Vorbereitungsfenster schließt sich im September.
Dieser Artikel basiert auf Daten von BigPanda/EMA, Information Technology Intelligence Consulting, Queue-it, Stord, Adobe Analytics. Die genannten Zahlen beziehen sich auf den Stand der jeweiligen Veröffentlichung.
Das sinnvolle Fenster liegt zwischen Juli und September. Der erste Testlauf zeigt die Kapazitätsgrenze und die Engpassliste, danach braucht es Zeit für Umbauten und einen zweiten Lauf, der die Wirkung belegt. Im Oktober folgen Notfallplan und Probelauf, ab etwa zwei Wochen vor dem ersten Aktionstag gilt ein Änderungsstopp. Wer erst im November beginnt, kann messen, aber kaum noch reagieren - und trifft dabei auf einen Traffic, der am Spitzentag rund doppelt so hoch liegt wie an einem normalen Oktobertag (Queue-it).
Die Zahl leitet sich aus den eigenen Vorjahresdaten ab, nicht aus einem Richtwert. Praktisch bewährt hat sich, den gemessenen Spitzenwert des Vorjahres mit dem erwarteten Wachstum zu multiplizieren und darauf eine Reserve von etwa 50 Prozent zu geben. Als Orientierung für die Größenordnung dienen die 2024 beobachtete Verdopplung des Traffics am Spitzentag (Queue-it) und der Anstieg des maximalen Tagesbestellvolumens um 252 Prozent im selben Jahr (Stord). Wichtiger als die absolute Zahl ist, dass der Test über den Planwert hinausgeht, bis eine Schwelle reißt.
Erfahrungsgemäß ist eine produktionsnahe Kopie die bessere Wahl, weil ein Lasttest gegen das Livesystem echte Bestellungen, Zahlungsvorgänge und Bestätigungsmails erzeugt und Schutzmechanismen die Last als Angriff werten können. Lässt sich eine Kopie nicht bereitstellen, gehört der Test in ein eng begrenztes Zeitfenster mit abgeschalteter Bestellstrecke und gesperrtem Mailversand, mit vorab informierten Dienstleistern und mit einer Person, die den Lauf jederzeit abbrechen kann.
Bewährt hat sich ein Dreiklang: ein Zielwert für den Normalbetrieb, etwa 0,8 Sekunden Serverantwort im 95. Perzentil, eine Warnschwelle bei etwa 1,5 Sekunden, die vorbereitete Entlastungen auslöst, und eine Notbremse bei etwa 2,5 Sekunden oder einer Fehlerrate über einem Prozent. Die konkreten Werte hängen vom Sortiment und vom Seitentyp ab und sollten getrennt für Kategorie-, Produkt- und Checkout-Seiten gelten. Gemessen wird das Perzentil, nicht der Mittelwert.
Benannte Rollen mit Erreichbarkeit und Vertretung, drei Eskalationsstufen mit klaren Auslösern, vorbereitete Lastventile zum Abschalten verzichtbarer Funktionen, vorbereitete Texte für Statusmeldung und Kundenservice, ein definierter Rückweg je Maßnahme und ein Protokoll. Der Plan sollte ausgedruckt vorliegen und mindestens einmal geprobt worden sein.
Wir leiten das Lastprofil aus Ihren Daten ab, bauen eine produktionsnahe Testumgebung auf und fahren den Stufentest bis zur Kapazitätsgrenze. Aus den Messwerten entstehen abgestimmte Schwellwerte, die im Monitoring hinterlegt werden, sowie ein dokumentierter Notfallplan mit geprüften Lastventilen. Über die Aktionswochen begleiten wir den Betrieb mit Bereitschaft und einem festen Kennzahlenbild. Typischerweise lässt sich der gesamte Ablauf zwischen Juli und Oktober planbar umsetzen.