Magento Full-Page-Cache-Warmup-Strategien gegen das Thundering-Herd-Problem

1. Warum ein leerer Cache nach Deployment zum Problem wird

Ein Full-Page-Cache-Flush ist in Magento ein alltäglicher Vorgang, er passiert bei jedem Deployment, nach Preisänderungen im großen Stil, nach Indexer-Läufen mit Full-Reindex oder schlicht durch einen manuellen bin/magento cache:flush. Unmittelbar danach ist der Full-Page-Cache vollständig leer, jede eingehende Anfrage muss die komplette Rendering-Pipeline durchlaufen: Layout laden, Blöcke aufbauen, Produktdaten aus der Datenbank ziehen, Preise berechnen und am Ende HTML ausgeben.

Bei niedrigem Traffic fällt das kaum auf, weil die Anfragen zeitlich verteilt eintreffen und der Cache sich Seite für Seite von selbst aufbaut. Bei einem Shop mit nennenswertem gleichzeitigem Traffic entsteht dagegen das klassische Thundering-Herd-Problem: Dutzende oder hunderte Besucher fragen innerhalb weniger Sekunden dieselbe, noch ungecachte Startseite oder Kategorieseite an, und der Server muss diese teure Anfrage mehrfach parallel und redundant verarbeiten, statt sie einmal zu berechnen und danach aus dem Cache zu bedienen. Das Ergebnis sind spürbar langsamere Antwortzeiten genau in dem Moment, in dem der Shop wieder online geht, und im schlimmsten Fall eine überlastete PHP-FPM- oder Datenbank-Schicht.

2. Kurzer technischer Hintergrund: Magento Full-Page-Cache

Magento unterstützt zwei Betriebsarten für den Full-Page-Cache: den eingebauten, dateibasierten oder Redis-gestützten Cache für kleinere Setups, und Varnish als vorgeschalteten HTTP-Reverse-Proxy für produktive Umgebungen mit höherem Traffic. In beiden Fällen gilt dasselbe Grundprinzip: Eine vollständig gerenderte HTML-Antwort wird unter einem Cache-Key gespeichert, der unter anderem aus der URL, dem Store-View und relevanten Cookies wie der Kundengruppe zusammengesetzt wird, und bei einem erneuten Request mit demselben Key wird die gespeicherte Antwort direkt ausgeliefert, ohne dass PHP überhaupt aufgerufen wird.

Genau diese Eigenschaft, dass ein Cache-Treffer PHP komplett umgeht, macht den Full-Page-Cache so wirkungsvoll für die Performance, aber auch so schmerzhaft leer nach einem Flush. Ein Varnish-Cache mit mehreren Gigabyte RAM kann theoretisch Zehntausende Seiten vorhalten, tut das aber erst, nachdem jede einzelne Seite mindestens einmal angefragt und dabei aus PHP gerendert wurde. Ohne aktives Warmup hängt der Füllstand des Caches also vollständig vom organischen Besucherverhalten ab, was in den ersten Minuten nach einem Flush zu einer sehr ungleichmäßigen und potenziell überlasteten Ausgangslage führt.

3. Unterschied zwischen reaktivem und proaktivem Cache-Warmup

Reaktives Warmup bedeutet, dass der Cache sich ausschliesslich durch eingehenden echten Besucher-Traffic aufbaut, ohne jeden gezielten Eingriff. Das ist die Standardeinstellung in praktisch jedem Magento-Setup und funktioniert bei niedrigem bis mittlerem Traffic ausreichend gut, weil sich der Cache innerhalb weniger Minuten von selbst füllt. Der Nachteil ist, dass genau die Besucher, die unmittelbar nach dem Flush eintreffen, die volle, ungecachte Rendering-Zeit spüren und im Zweifel sogar zur Überlastung beitragen, weil sie gemeinsam das Thundering-Herd-Problem auslösen.

Proaktives Warmup dreht diese Reihenfolge um: Ein automatisiertes Skript ruft die wichtigsten Seiten gezielt auf, bevor echte Besucher eintreffen, und füllt den Cache damit kontrolliert, in einem definierten Tempo und mit definierter Reihenfolge. Der entscheidende Unterschied liegt darin, dass proaktives Warmup vollständig unter der Kontrolle des Betreibers steht, während reaktives Warmup vom tatsächlichen, nicht vorhersehbaren Besucherverhalten abhängt. Für Shops mit planbaren Deployment-Fenstern oder nach großen Preis- und Katalogänderungen ist proaktives Warmup deshalb die deutlich zuverlässigere Strategie.

4. Priorisierung: Startseite, Top-Kategorien und Bestseller zuerst

Nicht jede Seite im Katalog verdient dieselbe Priorität beim Warmup, weil ein vollständiger Katalog mit mehreren zehntausend Produktseiten viel zu lange braucht, um komplett durchgewärmt zu werden, bevor der erste echte Besucher eintrifft. Sinnvoll ist eine klare Priorisierung nach tatsächlichem Traffic-Anteil: An erster Stelle steht die Startseite, weil sie fast jeder Besucher unabhängig vom Einstiegspunkt zumindest indirekt berührt und weil sie oft die komplexeste, am stärksten aggregierte Seite im gesamten Shop ist.

Danach folgen die Top-Kategorieseiten, typischerweise die 10 bis 30 meistbesuchten Kategorien laut Analytics-Daten, weil diese Seiten den Großteil des organischen und bezahlten Traffics abfangen. Als drittes werden die Bestseller-Produktseiten vorgewärmt, ermittelt entweder über die Magento-eigene Bestseller-Auswertung oder über die meistbesuchten Produkt-URLs aus dem Analytics-Tool. Alle übrigen Produktseiten werden bewusst dem reaktiven Warmup überlassen, weil sich der Aufwand für ein vollständiges Vorwärmen bei ihnen selten lohnt.

5. Systematisches Warmup per Skript

Ein Warmup-Skript benötigt eine Liste priorisierter URLs, typischerweise aus der Magento-Sitemap kombiniert mit einer manuell gepflegten Liste der wichtigsten Kategorien und einer dynamisch aus dem Bestseller-Report generierten Produktliste. Das folgende Beispiel zeigt ein einfaches, aber praxistaugliches Bash-Skript, das eine URL-Liste einliest und jede Seite per curl gezielt aufruft, um sie im Full-Page-Cache abzulegen, bevor der Traffic einsetzt.

Wichtig ist, dass das Skript denselben User-Agent und dieselben relevanten Cookies wie ein regulärer Besucher sendet, weil Magento den Cache-Key unter anderem anhand der Kundengruppe und des Store-Views bildet. Ein Warmup-Request ohne die passenden Cookies füllt sonst möglicherweise nur den Cache für eine Kundengruppe, während die tatsächlich häufigste Kundengruppe weiterhin kalt bleibt.

#!/usr/bin/env bash
set -euo pipefail

URL_LIST="var/warmup/priority-urls.txt"
CONCURRENCY=8
BASE_URL="https://www.beispielshop.de"

echo "Starte Cache-Warmup mit ${CONCURRENCY} parallelen Requests..."

cat "$URL_LIST" | xargs -P "$CONCURRENCY" -I{} curl \
    --silent \
    --output /dev/null \
    --write-out "%{http_code} %{time_total}s {}\n" \
    --header "User-Agent: MironsoftCacheWarmup/1.0" \
    --max-time 20 \
    "${BASE_URL}{}"

echo "Cache-Warmup abgeschlossen."

6. Parallelisierung und Rate-Limiting beim Warmup

Ein Warmup-Skript, das alle Seiten mit maximaler Parallelität abruft, kann den Server stärker belasten als das eigentliche Thundering-Herd-Problem, das es verhindern soll, weil jede noch ungecachte Seite eine vollständige PHP-Rendering-Anfrage auslöst. Eine moderate Parallelität von etwa 5 bis 10 gleichzeitigen Requests hat sich in der Praxis als guter Kompromiss erwiesen, der den Cache innerhalb weniger Minuten füllt, ohne PHP-FPM-Worker oder die Datenbankverbindungen vollständig auszulasten.

Zusätzlich lohnt es sich, das Warmup-Skript in Wellen zu strukturieren, bei denen zuerst die absolut kritischen Seiten wie Startseite und Top-Kategorien mit hoher Priorität abgearbeitet werden und danach, mit etwas geringerer Parallelität, die zweite Prioritätsstufe wie Bestseller-Produkte folgt. So ist der Shop bereits nach kurzer Zeit für den Großteil des erwarteten Traffics einsatzbereit, während die weniger kritischen Seiten im Hintergrund nachziehen, ohne die kritische Phase zu verlangsamen.

7. Integration in die Deployment-Pipeline

Damit Cache-Warmup nicht von manuellem Eingreifen abhängt, sollte es als fester, automatisierter Schritt direkt im Anschluss an cache:flush in der Deployment-Pipeline verankert werden. Ein typischer Ablauf sieht vor, dass nach dem Deployen des neuen Codes, dem Ausführen der Datenbank-Migrationen und dem abschliessenden Cache-Flush automatisch das Warmup-Skript gestartet wird, bevor der Load Balancer den Server wieder als aktiv markiert und echten Traffic zulässt.

Bei mehreren Application-Servern hinter einem Load Balancer bedeutet das konkret, dass ein Server erst dann aus dem Wartungsmodus oder dem Health-Check-Ausschluss entfernt wird, wenn das Warmup-Skript für diesen Server erfolgreich durchgelaufen ist. Dieses Muster, oft als Rolling Deployment mit vorgeschaltetem Warmup bezeichnet, sorgt dafür, dass zu keinem Zeitpunkt ein vollständig kalter Server live geschaltet wird und echten Traffic ohne jede Vorwärmung erhält.

8. Monitoring des Warmup-Erfolgs

Ein Warmup-Skript, das einfach durchläuft, ohne die tatsächlichen Ergebnisse zu prüfen, gibt keine Garantie dafür, dass der Cache am Ende wirklich gefüllt ist. Sinnvoll ist deshalb, nach dem Warmup gezielt den X-Magento-Cache-Debug-Header oder den entsprechenden Varnish-Header bei einem zweiten Request auf dieselben URLs zu prüfen, um zu bestätigen, dass die Antwort tatsächlich aus dem Cache und nicht erneut aus PHP kommt.

Ergänzend lohnt sich ein Blick auf die Cache-Hit-Rate direkt nach dem Deployment im Monitoring-System, etwa über Varnishstat oder ein entsprechendes Grafana-Dashboard, um zu erkennen, ob die Hit-Rate innerhalb der erwarteten Zeit auf ein normales Niveau ansteigt. Bleibt die Hit-Rate ungewöhnlich niedrig, deutet das entweder auf eine fehlerhafte URL-Liste im Warmup-Skript oder auf ein Problem mit dem Cache-Key selbst hin, etwa durch eine neu eingeführte, ungewollt cache-relevante Cookie- oder Session-Variable.

9. Grenzen des Warmups und Vergleich der Strategien

Cache-Warmup löst nicht jedes Performance-Problem: Personalisierte Inhalte, eingeloggte Kundenbereiche und der Checkout-Prozess sind aus dem Full-Page-Cache ohnehin ausgenommen und profitieren nicht vom Vorwärmen. Auch ein sehr großer, langtail-lastiger Katalog mit zehntausenden selten besuchten Produktseiten lässt sich realistisch nicht vollständig vorwärmen, hier bleibt reaktives Warmup durch echten Traffic die einzig praktikable Lösung. Die folgende Tabelle stellt die besprochenen Strategien im direkten Vergleich gegenüber.

10. Zusammenfassung

11. FAQ: FPC-Warmup-Strategien: Das Wichtigste auf einen Blick