4. Juni 2026, Luboš Zápotočný
Warum der Checkout bei 10 % Serverlast ausfällt
Server im Leerlauf, Checkout nicht erreichbar. Lock-Contention, Cache-Stampedes, synchrone Payment-Calls: Ausfallmuster, gegen die Autoscaling nicht hilft.
Es ist einer der am schwersten einzuordnenden Incidents für ein E-Commerce-Team. Die Kampagne geht live, beim Checkout häufen sich Timeouts, und die Dashboards zeigen unauffällige Werte: CPU bei 10 %, Speicher normal, reichlich freie Kapazität. Die naheliegende Reaktion ist, Server aufzustocken. Die neuen Server laufen ebenfalls im Leerlauf, und der Checkout ist weiterhin nicht erreichbar.
Die Verwirrung rührt von einem falschen Denkmodell her. Last hat zwei Komponenten: Arbeit und Warten. Ihre Server verbringen die Zeit in Warteschlangen, und Warteschlangen tauchen auf keinem CPU-Graphen auf.
Die häufigsten Ursachen
Lock-Contention in der Datenbank. Der Checkout ist die Stelle, an der der Shop aufhört zu lesen und anfängt zu schreiben: Bestand reservieren, Bestellung anlegen, Adresse speichern. Diese Writes werden über Row Locks serialisiert, und Kampagnen-Traffic konzentriert sie auf dieselben wenigen, stark frequentierten Zeilen: die Zähler der Bestellnummernsequenz, die Bestell- und Warenkorbtabellen, den Bestand, der gerade reserviert wird. Jede Transaktion hält ihre Locks, während sie auf den Abschluss anderer Vorgänge wartet. Der Durchsatz bricht ein, während die CPU-Auslastung niedrig bleibt. Auf Magento zeigt es sich in den Logs als Lock-Wait-Timeout- und Deadlock-Fehler von MySQL.
Cache-Stampedes. Ein stark frequentierter Cache-Eintrag, etwa die Kategorieseite, auf die jede Anzeige zeigt, läuft mitten in der Spitzenlast ab. Alle Requests, die den Eintrag jetzt nicht mehr vorfinden, regenerieren die Seite gleichzeitig und belasten die Datenbank mit identischen teuren Queries. Die Datenbank erhält eine Kopie dieser Arbeit pro gleichzeitigem Request.
Synchrone Drittanbieter-Calls im Checkout-Pfad. Versandkosten, Zahlungsautorisierung, Steuerberechnung, ein Anti-Fraud-Check: jeweils ein Netzwerkaufruf in das System von jemand anderem, während Ihr Worker eine Connection und oft eine Datenbanktransaktion hält. Wird ein Anbieter unter derselben Kampagnenlast von 200 ms auf 10 Sekunden langsam, wartet nach und nach jeder Worker in diesem Aufruf. Der Checkout bleibt dann so lange nicht erreichbar, wie dieser Anbieter langsam ist.
Erschöpfte Worker und Connections. Die drei oben genannten Probleme verstärken sich durch denselben Mechanismus: Worker, die warten, belegen trotzdem ihren Slot und ihre Datenbank-Connection. PHP-FPM-Prozesse, dimensioniert für gewöhnliche Wochentagslast, füllen sich mit blockierten Requests, neue Requests erhalten weder einen Worker noch eine Connection, und der Ausfall erfasst jede Seite, die noch einen PHP-Worker braucht, so wenig Arbeit diese Seite auch macht.
Keines der vier Probleme ist ein Hardware-Problem, weshalb Autoscaling es nicht behebt: Neue Instanzen stellen sich in dieselbe Schlange vor denselben Row Lock hinter demselben langsamen Anbieter. Zusätzliche Kapazität wartet parallel, statt Durchsatz zu liefern.
Wie Sie es frühzeitig erkennen
Für die Diagnose zählt weniger die Auslastung als die Zeit: Verbringt ein Checkout-Request seine Millisekunden mit Arbeit oder mit Warten auf Locks, Caches und Drittanbieter-APIs? Distributed Traces beantworten das direkt; ein Slow-Query-Log und die Lock-Wait-Zähler der Datenbank beantworten es mit geringem Aufwand. Wenn Sie vor der nächsten Kampagne nur einen einzigen Graphen dazunehmen, dann Lock-Waits.
Die Fixes folgen aus der Diagnose, und die meisten sind Routine: Timeouts für jeden Drittanbieter-Call und zwischengespeicherte Fallbacks überall dort, wo eine veraltete Antwort unschädlich ist (eine leicht veraltete Versandkostenauskunft schadet nicht, eine Zahlungsautorisierung muss dagegen live erfolgen), Stampede-Schutz, damit ein Prozess den stark frequentierten Key neu aufbaut, während die anderen den alten Stand ausliefern, die Verlagerung nicht essenzieller Writes aus der Transaktion in eine Queue, und die Reservierung des Bestands so spät im Funnel, wie es das Geschäft erlaubt, statt ihn schon ab dem Warenkorb zu halten. Welche davon für Ihren Shop zählen, ist eine empirische Frage. Ein Performance-Audit beantwortet sie aus Ihren eigenen Traces, und unsere DevOps-Arbeit sorgt dafür, dass die Fixes dauerhaft wirksam bleiben.
Die meisten dieser Incidents stellen sich als Concurrency-Probleme heraus. Sehen Sie sich deshalb zuerst einen Trace an, bevor Sie neue Server kaufen.