Varnish, Redis und OpenSearch Sidecars für Magento feintunen

1. Warum Sidecar-Tuning über Standard-Compose hinausgeht

Ein typisches Magento-Compose-Setup startet Varnish, Redis und OpenSearch als Sidecar-Container mit den Default-Einstellungen aus dem offiziellen Image. Das reicht für lokale Entwicklung völlig aus, aber unter Produktionslast mit Tausenden gleichzeitigen Sessions und einem großen Produktkatalog zeigen sich die Grenzen der Defaults schnell: Varnish cached zu aggressiv oder zu vorsichtig, Redis wirft Sessions weg, wenn der Speicher voll ist, und OpenSearch läuft mit einem Heap, der weder zu klein noch sinnvoll groß dimensioniert ist.

Sidecars feintunen bedeutet, jeden dieser drei Dienste anhand seiner tatsächlichen Rolle im Magento-Stack zu konfigurieren, statt sich auf die generischen Werksvorgaben zu verlassen, die für beliebige Anwendungsfälle gedacht sind. Ein Redis-Container, der gleichzeitig Sessions und Cache bedient, braucht andere Einstellungen als ein Redis, der nur für Cache zuständig ist. Ein Varnish vor einem Shop mit hoher Produktvarianz braucht andere TTL-Werte als einer vor einem Shop mit wenigen, selten wechselnden Produkten.

Dieser Artikel geht die drei wichtigsten Sidecars im Magento-Container-Stack durch und zeigt konkrete Konfigurationswerte für Varnish, Redis und OpenSearch, die über die Standard-Defaults hinausgehen und sich an der realen Last eines Magento-Shops orientieren.

2. Varnish VCL feintunen: TTL, Grace und Hit-Rate

Der Standard-VCL, den viele Magento-Docker-Images mitbringen, setzt eine pauschale TTL für alle gecachten Seiten. In der Praxis sollten Kategorieseiten mit häufig wechselnden Bestandsdaten eine kürzere TTL bekommen als statische CMS-Seiten. Das Varnish-Sidecar-Tuning beginnt damit, die TTL pro Content-Typ über die X-Magento-Tags-Header zu differenzieren, die Magento bereits für die Cache-Invalidierung mitliefert.

Die grace-Periode ist ein unterschätzter Parameter beim Varnish-Tuning: Sie erlaubt, eine abgelaufene, aber noch im Cache liegende Antwort auszuliefern, während im Hintergrund eine frische Version geholt wird. Ohne Grace-Periode wartet jeder Request nach TTL-Ablauf auf den vollständigen Backend-Roundtrip, was bei Lastspitzen zu einem sogenannten Thundering-Herd-Problem führt, wenn viele gleichzeitige Requests denselben abgelaufenen Cache-Eintrag treffen.

# default.vcl — differentiated TTL and grace period per content type
sub vcl_backend_response {
    # Category and product pages: shorter TTL, longer grace for stale-while-revalidate
    if (bereq.url ~ "^/catalog/category/view" || bereq.url ~ "^/catalog/product/view") {
        set beresp.ttl = 10m;
        set beresp.grace = 6h;
    }
    # Static CMS pages change rarely: longer TTL is safe
    elsif (bereq.url ~ "^/cms/") {
        set beresp.ttl = 24h;
        set beresp.grace = 24h;
    }
    # Default fallback for everything else
    else {
        set beresp.ttl = 1h;
        set beresp.grace = 1h;
    }

    # Keep serving stale content while Magento generates a fresh copy
    set beresp.keep = 24h;
}

Die Hit-Rate eines Varnish-Sidecars lässt sich über varnishstat beobachten, insbesondere die Metrik cache_hit im Verhältnis zu cache_miss. Eine Hit-Rate unter 85 Prozent bei einem Katalog-lastigen Shop deutet fast immer auf zu kurze TTLs oder auf zu viele Cache-Invalidierungen durch Produktänderungen hin, nicht auf ein grundsätzliches Problem mit Varnish selbst.

3. Varnish Storage-Backend: Malloc vs. File

Varnish unterstützt zwei Storage-Backends für den Cache: malloc, das den Cache vollständig im Arbeitsspeicher hält, und file, das eine Datei auf der Festplatte als Backing Store nutzt und vom Betriebssystem über den Page Cache verwaltet wird. Für ein Varnish-Sidecar in einem Container ist malloc fast immer die richtige Wahl, weil Container-Volumes für den file-Modus zusätzliche I/O-Overhead und Persistenzprobleme beim Container-Neustart mit sich bringen.

Die Größe des Malloc-Storage muss zur tatsächlichen Cache-Arbeitsmenge des Magento-Shops passen. Ein zu klein dimensionierter Storage führt zu vorzeitigem Eviction bereits gecachter Seiten, bevor deren TTL abgelaufen ist, was die Hit-Rate unnötig senkt. Als Faustregel gilt: Storage-Größe mindestens doppelt so groß wie die Summe aller einzigartigen Seiten-Varianten, die während eines typischen Tages angefragt werden, multipliziert mit der durchschnittlichen Antwortgröße.

4. Redis feintunen: maxmemory Policy und Eviction

Der wichtigste einzelne Parameter beim Redis-Sidecar-Tuning für Magento ist maxmemory-policy. Der Redis-Standardwert noeviction lässt Schreibbefehle mit einem Fehler fehlschlagen, sobald der konfigurierte Speicher voll ist, was bei einem Session-Redis dazu führt, dass Kunden plötzlich keinen neuen Warenkorb mehr anlegen können. Für Cache-Redis ist allkeys-lru die richtige Policy, weil sie automatisch die am längsten nicht genutzten Einträge verdrängt, sobald neuer Speicher benötigt wird.

Für Session-Redis dagegen ist volatile-lru in Kombination mit gesetzten TTLs auf jedem Session-Key die sicherere Wahl, weil sie nur Keys mit TTL evictet und niemals Keys ohne Ablaufzeit löscht, was bei fehlerhaft konfigurierten Sessions ohne TTL zu Datenverlust führen könnte. Wer Redis als Sidecar für beide Zwecke gleichzeitig nutzt, sollte Cache und Session in getrennten logischen Datenbanken mit jeweils passender Policy betreiben, statt eine einzige Policy für alles zu wählen.

# redis.conf — separate tuning for cache vs. session workloads
maxmemory 2gb
maxmemory-policy allkeys-lru

# Persistence tuned for a cache-heavy Magento workload
save ""
appendonly no

# Connection and timeout tuning for many short-lived PHP-FPM connections
timeout 300
tcp-keepalive 60
maxclients 10000

5. Redis Persistence: AOF vs. RDB im Container

Ein reiner Cache-Redis für Magento braucht in den meisten Fällen keine Persistenz, weil verlorene Cache-Einträge einfach neu aus MySQL berechnet werden. Für diesen Anwendungsfall sollte sowohl RDB-Snapshotting über save als auch appendonly deaktiviert werden, um CPU- und I/O-Last für nicht benötigte Persistenz zu vermeiden. Ein Session-Redis braucht dagegen mindestens ein moderates RDB-Snapshotting, damit ein Container-Neustart nicht alle aktiven Warenkörbe und Login-Sessions gleichzeitig löscht.

AOF (Append Only File) bietet höhere Datensicherheit als RDB, weil jeder Schreibbefehl protokolliert wird, kostet aber messbar mehr I/O pro Operation. Für ein Redis-Sidecar, das ausschließlich Sessions hält, ist appendfsync everysec ein guter Kompromiss zwischen Sicherheit und Performance, während appendfsync always nur für Zahlungsrelevante Daten gerechtfertigt ist, die in Magento aber ohnehin in MySQL statt in Redis liegen.

6. OpenSearch feintunen: JVM-Heap im Container

Die häufigste Fehlkonfiguration bei einem OpenSearch-Sidecar in Containern ist ein JVM-Heap, der entweder das gesamte verfügbare Container-Memory beansprucht oder pauschal auf einem generischen Standardwert belassen wird. Die empfohlene Faustregel ist, den Heap auf maximal 50 Prozent des dem Container zugewiesenen Arbeitsspeichers zu setzen, damit der restliche Speicher für den Lucene-Filesystem-Cache verfügbar bleibt, der für Suchperformance mindestens so wichtig ist wie der Heap selbst.

Zusätzlich sollte der Heap niemals 32 Gigabyte überschreiten, weil die JVM oberhalb dieser Grenze von komprimierten Object-Pointers auf unkomprimierte wechselt, was den effektiven Speicherverbrauch pro Objekt erhöht und die Performance trotz mehr zugewiesenem Speicher verschlechtern kann. Für die meisten Magento-Shops liegt ein sinnvoller Heap für OpenSearch zwischen 2 und 8 Gigabyte, abhängig von Katalogsgröße und Anzahl gleichzeitiger Suchanfragen.

# docker-compose.yml — OpenSearch sidecar with tuned JVM heap
services:
  opensearch:
    image: opensearchproject/opensearch:2
    environment:
      - "OPENSEARCH_JAVA_OPTS=-Xms4g -Xmx4g"
      - "DISABLE_SECURITY_PLUGIN=true"
      - "discovery.type=single-node"
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    deploy:
      resources:
        limits:
          memory: 8g

7. OpenSearch Shards und Replicas für den Magento-Katalog

Magento erstellt für den Produktkatalog standardmäßig einen Index pro Store View mit einer festen Anzahl Shards. Zu viele Shards für einen kleinen Katalog verschwenden Overhead, weil jeder Shard eigene Lucene-Segmente, eigene Dateihandles und eigenen Speicher-Overhead mitbringt. Für die meisten Magento-Shops mit weniger als einer Million Produkten pro Store View reicht ein einzelner Primary Shard pro Index völlig aus, während größere Kataloge von zwei bis drei Shards profitieren können.

Die Anzahl der Replicas beeinflusst sowohl Ausfallsicherheit als auch Lesegeschwindigkeit, weil Suchanfragen über alle Replica-Shards verteilt werden können. Für ein OpenSearch-Sidecar im Single-Node-Betrieb, wie es in vielen Magento-Docker-Setups üblich ist, ergibt eine Replica-Anzahl größer null aber keinen Sinn, weil Replicas auf demselben Knoten wie der Primary Shard keinen Ausfallschutz bieten. Erst in einem Multi-Node-OpenSearch-Cluster wird die Replica-Konfiguration relevant für Lastverteilung und Redundanz.

8. Verbindungspooling und Timeouts zwischen Magento und Sidecars

Jeder PHP-FPM-Worker in Magento öffnet bei Bedarf eigene Verbindungen zu Redis und OpenSearch, was bei hoher Parallelität schnell zu Hunderten gleichzeitigen Verbindungen zum jeweiligen Sidecar führen kann. Ohne konfiguriertes Connection-Timeout und ohne maxclients-Limit auf Redis-Seite können hängende PHP-FPM-Worker Verbindungen offen halten, bis der Sidecar selbst an seine Verbindungsgrenze stößt und neue Requests ablehnt.

Für Magentos env.php sollten die Timeout-Werte für Redis-Cache und Redis-Session explizit gesetzt werden, statt auf die Bibliotheks-Defaults zu vertrauen. Ein read_timeout von 2 bis 5 Sekunden verhindert, dass ein einzelner überlasteter Redis-Sidecar den gesamten PHP-FPM-Pool durch hängende Verbindungen blockiert. Für OpenSearch gilt dasselbe Prinzip: Der PHP-Client sollte ein explizites Connect- und Read-Timeout konfiguriert bekommen, damit ein einzelner langsamer Suchindex nicht die komplette Kategorieseite blockiert.

9. Tuning-Parameter und Monitoring-Kennzahlen im Vergleich

Jeder der drei Sidecars hat eigene kritische Kennzahlen, die im Monitoring beobachtet werden sollten, um rechtzeitig zu erkennen, wenn die Konfiguration nicht mehr zur tatsächlichen Last passt.

Diese vier Kennzahlen sollten fester Bestandteil jedes Magento-Monitorings sein, weil sie deutlich früher auf Fehlkonfiguration hinweisen als Symptome wie langsame Seitenladezeiten oder abgebrochene Checkouts, die erst auftreten, wenn ein Sidecar bereits an seiner Grenze arbeitet.

10. Zusammenfassung

Varnish, Redis und OpenSearch als Sidecars feintunen heißt vor allem, die Standard-Defaults der offiziellen Images kritisch zu hinterfragen und durch Werte zu ersetzen, die zur tatsächlichen Rolle im Magento-Stack passen. Varnish braucht differenzierte TTLs pro Content-Typ und eine ausreichend dimensionierte Grace-Periode gegen Thundering-Herd-Probleme. Redis braucht getrennte Eviction-Policies für Cache und Session, weil beide Workloads fundamental unterschiedliche Anforderungen an Datensicherheit haben.

OpenSearch braucht einen bewusst dimensionierten JVM-Heap, der die 32-Gigabyte-Grenze respektiert und ausreichend Speicher für den Lucene-Filesystem-Cache übrig lässt. Verbindungspooling und explizite Timeouts zwischen Magento und allen drei Sidecars verhindern, dass ein überlasteter Dienst den gesamten PHP-FPM-Pool durch hängende Verbindungen mit in die Knie zwingt. Mit diesen Anpassungen liefern die Sidecars die Performance, die ein Magento-Shop unter echter Last tatsächlich braucht.

11. FAQ: Varnish, Redis und OpenSearch Sidecars feintunen