Redis vs. Varnish: klare Rollenverteilung in Magento

1. Das haeufige Missverstaendnis: Redis oder Varnish

In vielen Diskussionen ueber Magento-Performance wird die Frage gestellt, ob ein Shop Redis oder Varnish braucht, als waeren beide austauschbare Alternativen fuer dieselbe Aufgabe. Diese Fragestellung ist bereits falsch gestellt: Redis und Varnish arbeiten auf komplett unterschiedlichen Ebenen des Request-Lebenszyklus und loesen unterschiedliche Probleme. Die Frage sollte nicht lauten, welches der beiden Systeme man einsetzt, sondern wie man beide sinnvoll kombiniert.

Redis ist ein In-Memory-Datenspeicher, der von Magento als Backend fuer den Objektcache, optional den Full-Page-Cache-Speicher und die Session-Verwaltung genutzt wird. Es operiert innerhalb der PHP-Anwendung und wird von Magento-Code direkt angesprochen. Varnish dagegen ist ein eigenstaendiger HTTP-Reverse-Proxy, der VOR dem Webserver und vor PHP-FPM sitzt und komplette HTTP-Antworten cacht. Ein Request, der von Varnish aus dem Cache beantwortet wird, erreicht PHP und damit auch Redis nie.

Diese fundamentale Unterscheidung ist der Schluessel zum Verstaendnis: Varnish verhindert, dass Magento und Redis ueberhaupt erst angefragt werden, waehrend Redis Magento beschleunigt, wenn es doch angefragt wird. Beide Systeme sind komplementaer, nicht konkurrierend, und ein produktionstauglicher Magento-Shop mit ernsthaftem Traffic nutzt in der Regel beide gleichzeitig.

2. Die Rolle von Redis: Cache-Backend und Session-Store

Redis uebernimmt in Magento drei klar abgegrenzte Aufgaben. Erstens den Objektcache, der berechnete Daten wie Layout-XML-Merges, Konfigurationswerte, EAV-Attributmetadaten und Blockdaten zwischengespeichert. Dieser Cache wird bei jedem Request gelesen, egal ob die Anfrage von einem eingeloggten Kunden oder einem Gast stammt, und egal ob die Seite am Ende von Varnish gecacht wird oder nicht.

Zweitens kann Redis als Speicher-Backend fuer den Full-Page-Cache dienen, wenn kein Varnish im Einsatz ist. In diesem Modus rendert Magento vollstaendige HTML-Seiten und speichert sie in Redis, sodass ein wiederholter Request dieselbe Seite ohne erneutes Rendering ausliefern kann, allerdings muss der Request trotzdem PHP und Magento durchlaufen, nur eben ohne die teure Rendering-Arbeit. Drittens speichert Redis Sessions, sodass Warenkorb-Inhalte, Login-Status und personalisierte Daten ueber mehrere Requests hinweg erhalten bleiben.

Wichtig ist: Alle drei Rollen von Redis setzen voraus, dass der Request tatsaechlich bei PHP ankommt. Redis kann Magento nicht davor bewahren, ueberhaupt gestartet zu werden, es kann nur den Aufwand innerhalb von Magento reduzieren, sobald es laeuft.

3. Die Rolle von Varnish: HTTP-Layer vor Magento

Varnish sitzt architektonisch vor dem gesamten Magento-Stack, meist direkt hinter dem Load Balancer oder sogar an dessen Stelle. Wenn ein Request eintrifft, prueft Varnish zuerst, ob eine passende Antwort bereits im eigenen In-Memory-Cache liegt. Ist das der Fall, liefert Varnish die komplette HTTP-Antwort direkt aus, ohne dass Nginx, PHP-FPM, Magento oder Redis jemals involviert werden. Diese Antwortzeit liegt typischerweise im niedrigen einstelligen Millisekundenbereich, weil Varnish in C geschrieben ist und ausschliesslich mit Arbeitsspeicher arbeitet.

Der entscheidende Architekturvorteil von Varnish ist, dass er die gesamte PHP-Verarbeitung fuer gecachte Seiten komplett umgeht. Waehrend ein Redis-gestuetzter Objektcache PHP-Verarbeitung beschleunigt, eliminiert Varnish sie fuer Full-Page-Cache-Hits vollstaendig. Der Unterschied macht sich vor allem bei hoher Traffic-Last bemerkbar: Ein Magento-Setup nur mit Redis, ohne Varnish, kann trotz schnellem Objektcache bei tausenden gleichzeitigen Requests an die PHP-FPM-Worker-Kapazitaet stossen, weil jeder Request weiterhin einen PHP-Prozess belegt. Mit Varnish davor werden anonyme, cachebare Seitenaufrufe von PHP-FPM komplett entkoppelt.

4. Der Weg eines Requests durch beide Layer

Um die Rollenverteilung konkret zu verstehen, hilft der Blick auf den tatsaechlichen Weg eines Requests. Bei einem Cache-Hit in Varnish endet der Weg bereits nach wenigen Millisekunden, ohne dass Magento oder Redis beteiligt sind. Bei einem Cache-Miss in Varnish, etwa fuer eine noch nicht gecachte Produktseite oder eine personalisierte Anfrage, wird der Request an den Webserver weitergereicht, der ihn an PHP-FPM und damit an Magento uebergibt.

Innerhalb von Magento greift dann der Objektcache in Redis, um teure Berechnungen zu vermeiden, waehrend die Session ebenfalls aus Redis gelesen wird, um den Nutzerkontext wiederherzustellen. Nach der vollstaendigen Verarbeitung liefert Magento die HTML-Antwort zurueck an Varnish, das sie, sofern cachebar, fuer zukuenftige Requests speichert und gleichzeitig an den aktuellen Client ausliefert.

# Request path visualization via response headers
curl -sI https://shop.example.com/catalog/category/view/id/42 | grep -iE "x-cache|x-magento-cache|age"

# Varnish cache hit: request never reached PHP
# X-Magento-Cache-Debug: HIT
# Age: 340

# Varnish cache miss: request went through PHP and Redis object cache
# X-Magento-Cache-Debug: MISS
# Age: 0

# Check Redis object cache hit ratio independently
redis-cli -p 6379 info stats | grep -E "keyspace_hits|keyspace_misses"

5. Varnish-Konfiguration fuer Magento

Magento generiert eine eigene VCL-Konfigurationsdatei ueber bin/magento varnish:vcl:generate, die als Ausgangspunkt fuer den Varnish-Cache-Layer dient. Diese Datei definiert, welche Requests cachebar sind, wie Cache-Tags fuer die Invalidierung genutzt werden, und wie Backend-Health-Checks konfiguriert sind. Sie muss in der Regel nur einmalig generiert und danach selten angepasst werden, ausser bei individuellen Anforderungen wie zusaetzlichen Cookies, die die Cachebarkeit beeinflussen.

# Generate the Varnish VCL configuration matching the running Magento instance
bin/magento varnish:vcl:generate --export-version=6 --access-list="10.0.0.0/24" > /etc/varnish/default.vcl

# Point Magento's cache configuration to Varnish as the caching application
# app/etc/env.php
# 'system' => [
#     'default' => [
#         'system' => [
#             'full_page_cache' => [
#                 'caching_application' => '2',
#                 'varnish' => [
#                     'access_list' => '10.0.0.0/24',
#                     'backend_host' => 'nginx',
#                     'backend_port' => '80',
#                 ],
#             ],
#         ],
#     ],
# ],

# Reload Varnish with the new configuration
varnishadm vcl.load new_config /etc/varnish/default.vcl
varnishadm vcl.use new_config

Nach jedem Deployment, das die Magento-Cache-Konfiguration betrifft, muss die VCL-Datei neu generiert und Varnish neu geladen werden, sonst laeuft Varnish mit einer veralteten Konfiguration weiter, die neue Cache-Tags oder geaenderte Backend-Einstellungen nicht kennt. Dieser Schritt gehoert fest in jede Magento-Deployment-Pipeline, die Varnish einsetzt.

6. Cache-Invalidierung: wie beide Systeme zusammenspielen

Wenn ein Produkt oder eine Kategorie in Magento geaendert wird, muessen sowohl der Redis-Objektcache als auch der Varnish-Full-Page-Cache invalidiert werden, aber ueber unterschiedliche Mechanismen. Der Objektcache in Redis wird ueber Cache-Tags invalidiert, die Magento intern verwaltet und die beim Speichern einer Entity automatisch geloescht werden. Varnish dagegen wird ueber HTTP-PURGE-Requests invalidiert, die Magento an Varnish sendet, sobald relevante Cache-Tags betroffen sind.

Diese doppelte Invalidierung laeuft in einer korrekt konfigurierten Umgebung automatisch und synchron ab: Beim Speichern eines Produkts loescht Magento die betroffenen Objektcache-Eintraege in Redis und sendet gleichzeitig einen PURGE-Request an Varnish fuer alle Seiten, die dieses Produkt referenzieren. Ein haeufiger Konfigurationsfehler ist, dass Varnish PURGE-Requests nur von bestimmten IP-Adressen akzeptiert, die im access_list-Parameter definiert sind. Fehlt die IP des Magento-Application-Servers in dieser Liste, schlagen PURGE-Requests fehl und Varnish liefert veraltete Seiten aus, obwohl der Redis-Objektcache bereits korrekt aktualisiert wurde.

# Manually verify the invalidation chain after a product save
# 1. Check the Redis object cache no longer holds the stale tag
redis-cli -p 6379 keys "*catalog_product_42*" | head -n 5

# 2. Confirm Varnish received and processed the PURGE request
varnishlog -q "ReqMethod eq \"PURGE\""

# 3. If PURGE requests fail, check the access list in the VCL
grep -A 5 "acl purge" /etc/varnish/default.vcl

# 4. Manually trigger a purge for a specific URL as a fallback
curl -X PURGE https://shop.example.com/catalog/product/view/id/42 \
  -H "Host: shop.example.com"

7. ESI: dynamische Inhalte in statischen Seiten

Eine besondere Herausforderung fuer Varnish sind personalisierte Inhalte auf ansonsten statischen Seiten, etwa der Warenkorb-Zaehler im Header oder personalisierte Produktempfehlungen. Wuerde die komplette Seite wegen dieser kleinen dynamischen Teile von der Cachebarkeit ausgeschlossen, ginge der gesamte Performance-Vorteil von Varnish verloren. Die Loesung ist Edge Side Includes: Varnish cacht die statische Haupt-Seite, laesst aber definierte Platzhalter offen, die bei jedem Request separat von Magento und Redis nachgeladen werden.

Diese ESI-Bloecke sind selbst wieder kleine Requests, die durch den PHP-Stack laufen und vom Redis-Objektcache profitieren, aber deutlich kleiner und schneller sind als eine komplette Seitenverarbeitung. Magento nutzt ESI standardmaessig fuer Elemente wie den Mini-Warenkorb, sodass der Rest der Seite, etwa Produktbeschreibung und Bildergalerie, vollstaendig von Varnish gecacht werden kann, waehrend nur der kleine personalisierte Teil bei jedem Request neu geladen wird.

# ESI tag as rendered inside an otherwise fully cached Magento page
# <esi:include src="/checkout/cart/miniCartCustomerData" />

# Confirm ESI processing is enabled in Varnish VCL
grep -A 3 "set beresp.do_esi" /etc/varnish/default.vcl

# Trace how often the ESI sub-request hits Redis object cache vs a fresh render
redis-cli -p 6379 monitor | grep -i "block_html\|mini_cart" &
curl -s https://shop.example.com/ > /dev/null

8. Magento ohne Varnish: wann das ausreicht

Nicht jeder Magento-Shop braucht zwingend Varnish. Fuer sehr kleine Shops mit geringem Traffic, wenigen gleichzeitigen Nutzern und ohne Traffic-Spitzen kann der interne Full-Page-Cache mit Redis als Backend ausreichend Performance liefern, ohne die zusaetzliche Betriebskomplexitaet eines separaten Varnish-Layers einzugehen. Der interne Full-Page-Cache ist zwar langsamer als Varnish, weil er PHP durchlaeuft, aber fuer geringe Lastspitzen oft vollkommen ausreichend.

Sobald ein Shop jedoch regelmaessig hunderte gleichzeitige Requests bedienen muss, etwa waehrend Werbekampagnen oder saisonalen Spitzen wie dem Black Friday, wird der Unterschied deutlich spuerbar. PHP-FPM-Worker sind eine begrenzte, teure Ressource, waehrend Varnish HTTP-Antworten mit minimalem Ressourcenverbrauch aus dem Arbeitsspeicher ausliefert. Fuer Shops mit signifikantem Traffic ist Varnish praktisch immer die bessere Investition als zusaetzliche PHP-FPM-Worker oder groessere Application-Server.

// app/etc/env.php: internal full page cache using Redis, no Varnish in front
'system' => [
    'default' => [
        'system' => [
            'full_page_cache' => [
                // caching_application 1 = built-in FPC backed by Redis
                'caching_application' => '1',
            ],
        ],
    ],
],
'cache' => [
    'frontend' => [
        'page_cache' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '10.0.1.20',
                'port' => '6381',
                'compress_data' => 1,
            ],
        ],
    ],
],

9. Redis und Varnish im direkten Vergleich

Die folgende Tabelle stellt beide Systeme entlang ihrer wichtigsten Eigenschaften gegenueber, um die komplementaeren Rollen greifbar zu machen.

Die Tabelle macht deutlich: Redis und Varnish stehen nicht in Konkurrenz zueinander, sondern decken unterschiedliche Abschnitte des Request-Lebenszyklus ab. Ein Magento-Shop mit ernsthaftem Traffic profitiert von beiden gleichzeitig, weil sie unterschiedliche Engpaesse loesen.

10. Zusammenfassung

Redis und Varnish sind keine konkurrierenden Alternativen, sondern zwei komplementaere Bausteine einer durchdachten Magento-Caching-Architektur. Redis agiert innerhalb der PHP-Anwendung als schnelles Backend fuer Objektcache und Sessions, waehrend Varnish als HTTP-Layer davor sitzt und komplette Seiten ausliefert, ohne dass PHP oder Redis jemals angesprochen werden. Diese Rollenverteilung ist der Grund, warum beide Systeme in produktionstauglichen Magento-Setups gemeinsam eingesetzt werden.

Die Invalidierung beider Layer muss synchron ablaufen, damit weder veraltete Objektcache-Eintraege noch veraltete Full-Page-Cache-Seiten ausgeliefert werden. ESI loest das Problem personalisierter Inhalte innerhalb statischer, von Varnish gecachter Seiten, indem nur die kleinen dynamischen Teile bei jedem Request nachgeladen werden. Wer beide Systeme in ihrer jeweiligen Rolle korrekt einsetzt, erreicht eine Performance, die keines der beiden Systeme allein erreichen koennte.

11. FAQ: Redis vs. Varnish in Magento