DE
EN
Ihr Shop bricht am Black Friday nicht zusammen, weil der Server zu klein ist. Er bricht zusammen, weil eine einzige Komponente zuerst nachgibt — und die ist fast nie die, an die man denkt. Dieser Beitrag zeigt die vier Engpässe in der Reihenfolge, in der sie in der Praxis auftreten, und welche Frage Sie Ihrem Hoster stellen sollten, bevor es ernst wird.
Im Technik-Check vom Freitag ging es um die vierzehn Punkte, die Sie selbst prüfen können. Bei einem davon wird es unangenehm konkret: der Ladezeit unter Last. Denn hier hört die Checkliste auf und die Infrastruktur fängt an.
Vorweg eine Entwarnung: Sie brauchen mit hoher Wahrscheinlichkeit keinen größeren Server. Sie brauchen zu wissen, wo Ihr aktueller zuerst nachgibt. Das ist eine andere Frage — und sie ist deutlich billiger zu beantworten.
Warum „läuft doch“ im November nicht mehr gilt
Der Normalbetrieb ist ein schlechter Ratgeber. Bei zwanzig gleichzeitigen Besuchern arbeitet Ihr Shop im Leerlauf: Jede Anfrage bekommt sofort einen freien Prozess, die Datenbank antwortet aus dem Arbeitsspeicher, Caches sind warm. Nichts davon gilt bei vierhundert.
Unter Last verhält sich ein System nicht linear, sondern in Stufen. Bis zu einem bestimmten Punkt passiert fast nichts — die Antwortzeit steigt von 300 auf 400 Millisekunden, kaum spürbar. Dann wird eine Ressource knapp, Anfragen beginnen zu warten, und die Antwortzeit springt von 400 Millisekunden auf acht Sekunden. Nicht schleichend. Sprunghaft.
Wie relevant das ist, zeigt der Blick auf die Umsatzverteilung: Der Internet- und Versandhandel lag im Dezember 2025 real 5,2 Prozent über dem Vorjahresmonat, im Gesamtjahr sogar 10,1 Prozent — nachzulesen in der Auswertung des Statistischen Bundesamtes zum Einzelhandelsumsatz. Die Besucher kommen also. Die Frage ist nur, ob Ihr Shop sie bedienen kann.
Die vier Engpässe — in der Reihenfolge, in der sie kippen
Wenn wir Shops unter Last setzen, gibt fast immer eine dieser vier Ressourcen zuerst nach. Die Reihenfolge ist erstaunlich stabil.
1. PHP-Worker: die häufigste Ursache, das kleinste Verständnis
Ihr Webserver hält eine feste Zahl von PHP-Prozessen bereit — oft zwischen 5 und 30. Jeder kann genau eine Anfrage gleichzeitig bearbeiten. Sind alle belegt, warten neue Anfragen in einer Schlange. Der Besucher sieht: nichts. Nur eine Seite, die lädt.
Das Tückische: Die Zahl der Worker ist nicht das Problem. Das Problem ist die Zeit, die jeder Worker belegt bleibt. Bei 20 Workern und 200 Millisekunden pro Anfrage schaffen Sie theoretisch 100 Anfragen pro Sekunde. Bei 20 Workern und zwei Sekunden pro Anfrage schaffen Sie zehn. Dieselbe Hardware, ein Zehntel der Kapazität.
Deshalb ist „mehr Worker“ selten die Lösung — sie brauchen alle Arbeitsspeicher. Die Lösung heißt fast immer: Anfragen schneller abarbeiten.
So finden Sie den Wert heraus: Schauen Sie in die Konfiguration Ihres PHP-FPM-Pools nach der maximalen Zahl gleichzeitiger Kindprozesse. Multiplizieren Sie sie mit dem Speicherlimit pro Prozess. Liegt das Ergebnis über dem verfügbaren Arbeitsspeicher, ist Ihr Server bei voller Auslastung rechnerisch überbucht — er funktioniert nur, solange nie alle Prozesse gleichzeitig ihr Limit ausschöpfen. Im Dezember tun sie das.
2. Datenbank: der Engpass hinter dem Engpass
Wenn ein Worker zwei Sekunden belegt bleibt, wartet er meistens auf die Datenbank. Typische Ursachen sind eine Kategorieansicht mit mehreren Filtern, eine Suchanfrage ohne passenden Index oder ein Bericht im Backend, den jemand ausgerechnet am Black Friday aufruft.
Besonders unangenehm sind Abfragen, die im Testsystem harmlos aussehen. Eine Kategorieabfrage über 200 Produkte läuft in 30 Millisekunden. Dieselbe Abfrage über 8.000 Produkte mit drei aktiven Filtern kann 1,5 Sekunden brauchen — und sie wird erst dann ausgeführt, wenn ein Kunde genau diese Filterkombination wählt. Im Dezember wählt sie jemand.
Fast jedes Shopsystem bringt ein Log für langsame Abfragen mit. Schalten Sie es für eine Woche ein, mit einem Schwellwert von einer Sekunde. Was danach in der Liste steht, ist Ihre Aufgabenliste — sortiert nach Dringlichkeit, ganz ohne Beratung.
3. Cache: hilft nur, solange er warm ist
Ein Cache beschleunigt nichts, was er nicht kennt. Genau das ist im Weihnachtsgeschäft die Falle: Ihre Kampagnen bringen Besucher auf Seiten, die vorher kaum jemand aufgerufen hat — Kategorie-Kombinationen, Filterseiten, Suchergebnisse. Jeder dieser Aufrufe ist ein Volltreffer ins Nichts und erzeugt genau die teure Datenbankabfrage aus Punkt 2.
Rechnen Sie einmal nach, wie viele Kombinationen Ihre Kategorieseiten erzeugen: Bei fünf Filtern mit je vier Optionen sind das über tausend mögliche Seiten. Kein Cache hält die alle vor. Deshalb ist es sinnvoller, die zehn häufigsten Kombinationen vorzuwärmen, als auf eine hohe Cache-Quote zu hoffen.
Zweite Falle: Ein Cache, der bei jeder Bestandsänderung komplett geleert wird. Im Dezember ändern sich Bestände im Minutentakt. Prüfen Sie, ob Ihr System gezielt einzelne Einträge invalidiert oder mit dem Vorschlaghammer arbeitet.
4. Netzwerk und TTFB: der Rest
Erst an vierter Stelle kommt das, woran die meisten zuerst denken: Bandbreite und Serverstandort. Für einen deutschen Shop mit deutschen Kunden ist das selten der Engpass — vorausgesetzt, der Server steht in Europa und die Bilder sind in vernünftigen Formaten ausgeliefert.
Relevant wird es bei der Time to First Byte: Wie lange dauert es, bis der Server überhaupt anfängt zu antworten? Steigt dieser Wert unter Last stark an, liegt die Ursache immer in den Punkten 1 bis 3 — nie im Netzwerk selbst.
Welche Hosting-Form Sie wirklich brauchen
Die ehrliche Antwort lautet: Es hängt weniger vom Umsatz ab als von der Frage, was passiert, wenn es eng wird. Diese Übersicht hilft bei der Einordnung.
| Hosting-Form | Passt für | Grenze im Peak |
|---|---|---|
| Shared Hosting | kleine Shops, wenige Bestellungen täglich | Nachbarn auf demselben Server beeinflussen Sie; Worker-Zahl meist nicht anpassbar |
| Managed Server / VPS | der Regelfall für ernsthafte Shops | Ressourcen fest; Skalierung braucht Vorlauf, aber Sie kontrollieren die Konfiguration |
| Dedizierter Server | hohe, gut planbare Last | keine schnelle Aufstockung — was drin ist, ist drin |
| Cloud / Autoscaling | stark schwankende Last, Kampagnenspitzen | skaliert Webserver, nicht die Datenbank; Kosten schwer planbar |
Der häufigste Irrtum steckt in der letzten Zeile: Autoscaling verdoppelt bei Bedarf die Webserver, aber die Datenbank bleibt dieselbe. Wenn Ihr Engpass in Punkt 2 liegt, macht Autoscaling die Sache sogar schlimmer — mehr Prozesse fragen dieselbe überlastete Datenbank.
Verfügbarkeit ist eine Entscheidung, kein Zufall
Hier lohnt ein Blick über den Tellerrand des E-Commerce. Das Bundesamt für Sicherheit in der Informationstechnik unterscheidet Verfügbarkeit in klar definierte Klassen — von „normal“ bis „hochverfügbar“ — und macht dabei deutlich, dass höhere Klassen nicht durch bessere Hardware entstehen, sondern durch Redundanz, Prozesse und geübte Wiederanläufe. Die Grundlagen sind in der BSI-Einführung zur Hochverfügbarkeit beschrieben.
Für einen Onlineshop heißt das übersetzt: Fragen Sie nicht „wie schnell ist der Server“, sondern „was passiert, wenn er ausfällt“. Wie lange dauert es, bis jemand es merkt? Wie lange bis zum Wiederanlauf? Und wurde dieser Wiederanlauf jemals geprobt?
Wer tiefer einsteigen möchte: Der IT-Grundschutz-Baustein APP.3.1 zu Webanwendungen und Webservices beschreibt die Anforderungen an Betrieb und Absicherung — inklusive der oft übersehenen Punkte Protokollierung und Lastbegrenzung.
Drei Mythen, die im November teuer werden
Bevor wir zum Messen kommen, drei Annahmen, die uns in Gesprächen immer wieder begegnen — und die in der Hochsaison Geld kosten.
„Wir haben doch genug Arbeitsspeicher“
Arbeitsspeicher ist selten der Engpass, sondern die Folge einer Entscheidung: Er begrenzt, wie viele PHP-Prozesse gleichzeitig laufen können. Wenn jeder Prozess 256 MB reserviert und der Server 8 GB hat, sind bei 30 Prozessen die Grenzen erreicht — unabhängig davon, wie schnell die CPU ist. Wer die Prozesszahl erhöht, ohne den Speicherbedarf pro Prozess zu senken, handelt sich Swapping ein. Und ein swappender Server ist langsamer als ein ausgelasteter.
„Der Shop war letztes Jahr auch schnell“
Ein Shop wird über das Jahr langsamer, ohne dass jemand etwas falsch macht. Der Katalog wächst, Logtabellen füllen sich, Erweiterungen kommen dazu, jede mit eigenen Abfragen. Ein System, das im Januar bei 300 Millisekunden lag, liegt im August oft bei 600 — bei identischer Hardware und identischem Traffic. Das ist normal. Problematisch wird es nur, wenn niemand es misst.
„Im Notfall stocken wir kurzfristig auf“
Diese Annahme stimmt bei Cloud-Anbietern und stimmt bei Managed Hosting oft nicht. Eine Aufstockung kann dort einen Umzug bedeuten, mit Ankündigungsfrist und Wartungsfenster. Genau deshalb steht diese Frage in der Liste weiter unten: Sie wollen die Antwort im August kennen, nicht am 25. November.
Der unterschätzte Faktor: Ihr eigenes Backend
Ein Punkt, der in keiner Hosting-Broschüre steht: Ihr Team belastet denselben Server. Ein Produktexport, ein Bericht über alle Bestellungen des Monats, ein Bulk-Update von Preisen — solche Vorgänge belegen PHP-Prozesse und Datenbankverbindungen, die dann für Kunden fehlen.
Legen Sie für die Peak-Wochen eine einfache Regel fest: keine Exporte, keine Massenänderungen und keine Auswertungen zwischen 17 und 22 Uhr. Das kostet nichts und wirkt sofort.
Was Sie messen müssen — und was Sie messen können
Ein Lasttest klingt nach großem Werkzeug, ist aber in der Grundform simpel: Sie schicken eine steigende Zahl gleichzeitiger Anfragen auf typische Seiten und beobachten, ab wann die Antwortzeit kippt.
Wichtig ist die Auswahl der Seiten. Testen Sie nicht die Startseite — die ist meistens gut gecacht und damit wenig aussagekräftig. Testen Sie eine Kategorieseite mit aktiven Filtern, eine Suchergebnisseite und den Warenkorb. Das sind die Seiten, die im Dezember Last erzeugen.
Für die reine Nutzererfahrung gelten daneben feste Schwellwerte, die Google in seiner Dokumentation zu den Core Web Vitals festgelegt hat: 2,5 Sekunden für den größten sichtbaren Inhalt, 200 Millisekunden für die Reaktion auf Eingaben, 0,1 für die Layoutstabilität. Diese Werte gelten für echte Nutzer im Feld — also inklusive der Besucher, die am Black Friday um 20 Uhr kommen. Was die drei Kennzahlen im Einzelnen bedeuten, haben wir in unserem Beitrag zu INP, LCP und CLS auseinandergenommen.
Die fünf Fragen an Ihren Hoster
Sie müssen kein Systemadministrator sein, um die richtigen Fragen zu stellen. Diese fünf reichen, um einzuschätzen, ob Ihr Hosting für den Peak taugt — und die Antworten sagen oft mehr über den Anbieter aus als jede Leistungsbeschreibung.
Erstens: Wie viele PHP-Prozesse stehen meinem Shop gleichzeitig zur Verfügung, und wie viel Arbeitsspeicher hat jeder? Zweitens: Wo läuft die Datenbank — auf demselben Server oder getrennt, und wie viel Speicher hat sie? Drittens: Kann ich für November kurzfristig aufstocken, und wie lange dauert das? Viertens: Wie erfahre ich von einem Ausfall — und wie schnell? Fünftens: Wann wurde zuletzt ein Wiederanlauf aus dem Backup geprobt?
Wenn Sie auf Frage fünf keine Antwort bekommen, haben Sie Ihre wichtigste Information bereits.
Was Sie diese Woche tun können
Drei Dinge, die keinen Vertrag und kein Budget brauchen. Erstens: Schalten Sie das Log für langsame Datenbankabfragen ein, Schwellwert eine Sekunde. In einer Woche haben Sie eine belastbare Liste. Zweitens: Rufen Sie eine gefilterte Kategorieseite auf und messen Sie die Zeit bis zum ersten Byte — einmal morgens, einmal abends. Weicht das stark ab, haben Sie ein Lastproblem, kein Ladezeitproblem. Drittens: Stellen Sie Ihrem Hoster die fünf Fragen. Per E-Mail, damit Sie die Antworten schriftlich haben.
Häufige Fragen zu Hosting und Last im Onlineshop
Wie viele gleichzeitige Besucher hält mein Shop aus?
Das lässt sich nicht aus der Serverausstattung ableiten, sondern nur messen. Entscheidend ist nicht die Besucherzahl, sondern wie lange eine durchschnittliche Anfrage einen PHP-Prozess belegt. Bei 20 Prozessen und 200 Millisekunden pro Anfrage sind theoretisch rund 100 Anfragen pro Sekunde möglich, bei zwei Sekunden nur noch zehn — bei identischer Hardware.
Bringt ein größerer Server mehr Sicherheit für den Peak?
Nur, wenn der Engpass tatsächlich bei CPU oder Arbeitsspeicher liegt. In der Praxis liegt er meist bei langsamen Datenbankabfragen oder bei Erweiterungen, die externe Schnittstellen synchron abfragen. Diese Probleme skalieren nicht mit Hardware — ein doppelt so großer Server wartet nur doppelt so komfortabel.
Was ist der Unterschied zwischen Ladezeit und Ladezeit unter Last?
Die übliche Messung erfolgt mit einem einzelnen Abruf auf ein ausgeruhtes System. Unter Last konkurrieren viele Anfragen um dieselben Ressourcen: PHP-Prozesse, Datenbankverbindungen, Cache-Speicher. Ein Shop, der im Leerlauf in 1,2 Sekunden lädt, kann bei vierhundert gleichzeitigen Besuchern bei acht Sekunden liegen.
Lohnt sich ein CDN für einen deutschen Onlineshop?
Für Bilder, Schriften und statische Dateien ja — es entlastet den Server spürbar. Für die dynamischen Seiten eines Shops mit ausschließlich deutschen Kunden ist der Effekt gering, weil die Wege ohnehin kurz sind. Ein CDN ersetzt keine Optimierung der Datenbank.
Was bedeutet Autoscaling für einen Onlineshop?
Autoscaling startet bei steigender Last automatisch zusätzliche Webserver. Das hilft, wenn der Engpass bei den PHP-Prozessen liegt. Es hilft nicht, wenn die Datenbank der Engpass ist — die bleibt in den meisten Setups eine einzelne Instanz, und mehr Webserver erhöhen dort sogar den Druck.
Wann sollte ich den Hoster wechseln?
Nicht im Oktober und keinesfalls im November. Ein Hosting-Umzug gehört in den August oder September, weil danach die Zeit für Tests fehlt. Wenn Sie jetzt feststellen, dass Ihr aktuelles Hosting nicht reicht, ist der Wechsel möglich. Ab Anfang Oktober arbeiten Sie besser mit dem, was da ist, und optimieren die Anwendung.
Fazit: Erst messen, dann kaufen
Die teuerste Entscheidung vor der Hochsaison ist ein größerer Server, der das eigentliche Problem nicht löst. Die günstigste ist eine Woche mit eingeschaltetem Slow-Query-Log.
Beides beantwortet dieselbe Frage — nur kostet das eine Geld und das andere Aufmerksamkeit. Und in den allermeisten Fällen, die wir gesehen haben, lag die Lösung nicht in mehr Hardware, sondern in drei oder vier Abfragen, die niemand je angeschaut hatte.
Wo gibt Ihr Shop zuerst nach?
Haben Sie schon einmal einen Lasttest gemacht — und was kam dabei heraus? Mich interessiert besonders, ob sich die Reihenfolge aus diesem Beitrag bei Ihnen bestätigt hat oder ob bei Ihnen etwas ganz anderes zuerst nachgab.
Und die Frage, die vermutlich die interessanteren Antworten bringt: Welche Antwort haben Sie von Ihrem Hoster auf Frage fünf bekommen? Schreiben Sie es in die Kommentare — anonymisiert, versteht sich. Aus solchen Erfahrungsberichten lernen alle mehr als aus jeder Leistungsbeschreibung.
Wenn Sie wissen möchten, wie Ihr Shop technisch dasteht, bevor die Last kommt: Unser kostenloser Technik- und Sichtbarkeits-Check analysiert jede Website ohne Anmeldung. Und wenn Sie einen Lasttest lieber begleitet durchführen möchten, erreichen Sie uns über die Kontaktseite.
Dieser Beitrag ist Teil unserer Q4-Serie. Jeden Dienstag erscheint hier ein neuer Beitrag zur Vorbereitung auf die Hochsaison. Nächste Woche: Der Produktdaten-Feed vor der Saison — Google Shopping, Marktplätze und die typischen Fehlerquellen.
Seien Sie der Erste, der einen Kommentar hinterlässt!