Eine schnelle Auslieferung von Seiten entscheidet im E-Commerce über Umsatz: Bereits 100 Millisekunden zusätzliche Ladezeit kosteten Amazon 1% Umsatz (Amazon), und eine Verzögerung von einer Sekunde reduziert Conversions um bis zu 7% (Akamai). Genau hier setzt Redis an. Als In-Memory-Cache liefert Redis Daten mit Sub-Millisekunden-Latenz und über 100.000 Operationen pro Sekunde (Redis Docs) - statt teurer Datenbankabfragen, die ein Vielfaches an Zeit benötigen. Für Shopware 6 lässt sich Redis als HTTP-Cache, Object-Cache und Session-Speicher einsetzen und kann die Ladezeiten um bis zu 40% verkürzen (Hosted Power). Dieser Leitfaden zeigt, wie Sie Redis als zentrale Cache-Schicht in Shopware konfigurieren, Cache-Invalidierung und Warmup beherrschen, im Cluster betreiben und die Hit-Rate gezielt optimieren - abgestimmt auf ein leistungsfähiges Hosting.
Warum Redis als Cache-Schicht in Shopware sinnvoll ist
Shopware 6 basiert auf Symfony und nutzt ein mehrschichtiges Caching-System. Standardmäßig landen viele Cache-Daten im Dateisystem. Das funktioniert, skaliert aber schlecht: Dateizugriffe sind langsamer als Speicherzugriffe, und bei mehreren Webservern hinter einem Load Balancer fehlt ein gemeinsamer Cache. Redis ist ein In-Memory-Key-Value-Store, der Daten direkt im Arbeitsspeicher hält und damit für häufig abgerufene, leicht regenerierbare Daten prädestiniert ist.
Der Geschwindigkeitsunterschied ist erheblich: In Vergleichsmessungen liefert ein In-Memory-Cache Leseoperationen um bis zu 80-mal schneller als eine relationale Datenbank (AWS). Während eine Datenbankabfrage je nach Komplexität zweistellige bis dreistellige Millisekunden kosten kann, antwortet Redis in der Regel im Sub-Millisekunden-Bereich (Redis Docs). Multipliziert mit Dutzenden Abfragen pro Seitenaufruf summiert sich das zu spürbar kürzeren Antwortzeiten - und damit zu besseren Core Web Vitals und höheren Conversion-Raten.
In-Memory-Tempo
Redis liefert 100.000+ Operationen pro Sekunde bei Sub-Millisekunden-Latenz (Redis Docs) - deutlich schneller als Datei- oder Datenbankzugriffe.
Geteilter Cache im Cluster
Mehrere Webserver greifen auf denselben Redis zu. Voraussetzung für Auto-Scaling bei Traffic-Spitzen ohne inkonsistente Caches.
Messbarer Effekt
Bis zu 40% kürzere Ladezeiten durch In-Memory-Caching (Hosted Power) und Wegfall von Session-Sperren im Checkout.
Wichtig ist die Einordnung: Redis ersetzt nicht die Datenbank. Die MySQL- bzw. MariaDB-Datenbank bleibt die verlässliche Quelle der Wahrheit. Redis ist die schnelle Zwischenschicht, die wiederkehrende Lesezugriffe abfängt. Bei einem Cache-Hit liefert Redis die Daten sofort; bei einem Cache-Miss fällt die Anfrage auf die Datenbank zurück, das Ergebnis wird berechnet und anschließend in Redis abgelegt. Genau dieser Fluss ist im Architektur-Diagramm oben dargestellt.
HTTP-Cache, Object-Cache und Session: die drei Schichten
Shopware kennt mehrere Cache-Bereiche, die unterschiedlichen Zwecken dienen. Für die Performance am wichtigsten ist der HTTP-Cache (Full Page Cache): Er speichert die fertig gerenderte HTML-Seite. Wird dieselbe Seite erneut angefordert, liefert der Cache sie aus, ohne dass PHP, Twig-Rendering und Datenbank überhaupt aktiv werden. Das ist der größte Performance-Hebel für Kategorie- und Produktseiten mit hohem Traffic.
Der Object-Cache liegt eine Ebene tiefer: Hier landen Ergebnisse aus dem Data Abstraction Layer (DAL), also vorbereitete Produktdaten, Konfigurationen und Entitäten. Benötigt Shopware Produktinformationen, prüft es zunächst diesen Cache. Der Session- und Warenkorb-Speicher schließlich hält nutzerspezifische Daten. Gerade Sessions profitieren von Redis, weil dateibasierte PHP-Sessions ein bekanntes Problem haben: Session-Locking.
| Cache-Schicht | Inhalt | Redis-Datentyp | Eviction-Policy |
|---|---|---|---|
| HTTP-Cache | Fertige HTML-Seiten | Ephemer (regenerierbar) | volatile-lru |
| Object-Cache (DAL) | Produktdaten, Entitäten | Ephemer (regenerierbar) | volatile-lru / allkeys-lru |
| Session | Login, Präferenzen | Alternd (mit TTL) | allkeys-lru |
| Warenkorb / Number Ranges | Kritische Daten | Persistent (RDB + AOF) | volatile-lru |
Dateibasierte PHP-Sessions sperren die Session-Datei während eines Requests. Treffen zwei parallele Anfragen desselben Nutzers ein, muss die zweite warten, bis die erste fertig ist. In der Praxis bedeutet das: Statt dass beide Anfragen in rund 350 ms abschließen, dauert die zweite 700 ms, weil sie auf die Freigabe der Sperre wartet (ma.ttias.be). Im Checkout mit parallelen AJAX-Requests ist das spürbar. Ein gemeinsamer Session-Speicher in Redis entschärft dieses Verhalten und ist Voraussetzung für den Betrieb mehrerer Webserver.
Nicht jede Anfrage ist cachebar. Der HTTP-Cache greift vor allem für anonyme Besucher und statische Seitenbereiche; sobald nutzerspezifische Inhalte wie der gefüllte Warenkorb oder ein eingeloggter Kundenbereich ins Spiel kommen, werden diese Teile dynamisch nachgeladen oder vom Caching ausgenommen. Shopware löst das über sogenannte ESI-Fragmente und Cache-Cookies, die dynamische Bereiche von der statischen Seite trennen. Für die Konfiguration heißt das: Je sauberer dynamische und statische Inhalte getrennt sind, desto größer ist der Anteil cachebarer Anfragen - und desto höher fällt die Hit-Rate aus.
Redis für Shopware 6 konfigurieren
Die Anbindung von Redis erfolgt über die YAML-Konfiguration von Shopware. Dabei werden die einzelnen Cache-Adapter auf Redis umgestellt. Die offizielle Shopware-Dokumentation empfiehlt ausdrücklich, für unterschiedliche Aufgaben getrennte Redis-Instanzen zu verwenden, da aktuelle Redis-Versionen innerhalb einer Instanz nur eine einzige Eviction-Policy anwenden können (Shopware Docs).
# Beispielhafte Zuordnung getrennter Redis-Instanzen
shopware:
cache:
redis_url: 'redis://cache-redis:6379/0?persistent=1'
framework:
cache:
app: cache.adapter.redis
default_redis_provider: 'redis://cache-redis:6379/0'
session:
handler_id: 'redis://session-redis:6379/0'
# Kritische Daten (Warenkorb, Number Ranges)
# in eigener Instanz mit RDB + AOF PersistenzSteht eine Cache-Instanz auf noeviction, lehnt Redis Schreibzugriffe ab, sobald maxmemory erreicht ist - Shopware wirft dann Fehler und der Shop kann ausfallen (Kickbyte). Für ephemere Caches empfiehlt sich volatile-lru bzw. allkeys-lru. Ebenso kritisch: eine fehlende maxmemory-Grenze. Ohne Limit wächst Redis, bis der Arbeitsspeicher des Hosts erschöpft ist - im schlimmsten Fall beendet der Linux-OOM-Killer den MySQL-Prozess (Kickbyte). Und: Redis und Swap vertragen sich nicht - eine swappende Redis-Instanz ist langsamer als ein direkter MariaDB-Zugriff (Kickbyte).
Ein häufiger Konfigurationsfehler ist die Nutzung einer einzigen gemeinsamen Redis-Instanz für Cache, Sessions und Warenkörbe. Das führt zu Ressourcenkonkurrenz: Cache-Daten konkurrieren mit Session- und Warenkorb-Daten um den Speicher. Greift die Eviction, werden womöglich aktive Warenkörbe gelöscht - Kunden verlieren im Checkout ihre Artikel (Kickbyte). Beim Umstieg auf einen Redis-Warenkorb ist außerdem der Befehl bin/console cart:migrate erforderlich, sonst gehen bestehende Warenkörbe verloren (Kickbyte).
Cache-Invalidierung: Datenaktualität ohne Performance-Verlust
Die zentrale Herausforderung jedes Caches lautet: Wie bleiben die ausgelieferten Daten aktuell, ohne den Performance-Vorteil zu verlieren? Shopware löst das über tag-basierte Invalidierung. Jede gecachte Antwort wird mit Cache-Tags versehen, die alle während des Requests verwendeten Entitäten kennzeichnen. Ändert sich ein Produkt, werden gezielt nur die Cache-Einträge mit dem passenden Tag invalidiert - nicht der gesamte Cache.
Seit Shopware 6.7 erfolgt die Invalidierung zudem verzögert: Cache-Löschungen passieren nicht mehr sofort beim Speichern, sondern werden gesammelt und über die Message Queue verarbeitet - standardmäßig alle 5 Minuten (Shopware Docs). Das verhindert, dass viele kleine Änderungen den Cache permanent leeren und so die Hit-Rate zerstören. Wer Redis nutzt, sollte laut Dokumentation auch den Speicher für die verzögerte Invalidierung auf Redis legen; der MySQL-Adapter ist nur als Fallback gedacht (Shopware Docs).
- Tag-basiert statt global - nur betroffene Einträge invalidieren, der Rest des Caches bleibt warm
- Verzögerte Invalidierung - Änderungen sammeln und gebündelt verarbeiten (Standard: alle 5 Minuten, Shopware 6.7)
- Reverse Proxy beachten - bei vorgelagertem CDN oder Varnish muss der Cache auch dort geleert werden
- Stock-Änderungen prüfen - Lagerbestände und Preise brauchen oft eine engere Invalidierung als statische Inhalte
In der Praxis ist die Balance entscheidend: Eine zu aggressive Invalidierung leert den Cache ständig und macht ihn wirkungslos, eine zu träge Invalidierung liefert veraltete Preise oder Lagerbestände aus. Für die meisten Shops ist die verzögerte, tag-basierte Strategie ein guter Mittelweg. Bei zeitkritischen Daten wie Restbeständen empfiehlt sich eine ergänzende, gezielte Invalidierung dieser spezifischen Entitäten.
Cache-Warmup: kalte Caches vermeiden
Ein leerer Cache nach einem Deployment, einer Invalidierung oder einem Neustart bedeutet: Die ersten Besucher treffen auf einen Cache-Miss und müssen auf die volle Berechnung warten. Bei hohem Traffic können viele gleichzeitige Misses die Datenbank kurzfristig stark belasten - ein Effekt, der als Cache-Stampede bekannt ist. Das Cache-Warmup beugt vor, indem die wichtigsten Seiten vorab gerendert und in den Cache geschrieben werden.
Shopware stellt dafür den Befehl bin/console cache:warmup bereit. Der früher genutzte Befehl http:cache:warm:up gilt seit Shopware 6.5/6.6 als veraltet; stattdessen empfiehlt sich das Vorwärmen über externe Crawler, die die Sitemap abarbeiten (Shopware Docs). In der Praxis wird das Warmup typischerweise direkt nach einem Deployment automatisiert ausgeführt, sodass produktive Besucher von Beginn an auf warme Caches treffen.
Ein automatisiertes Cache-Warmup nach jedem Deployment stellt sicher, dass die umsatzstärksten Seiten - Startseite, Top-Kategorien, Bestseller - bereits beim ersten Aufruf aus dem Cache kommen. Erfahrungsgemäß lohnt es sich, das Warmup auf die meistbesuchten URLs zu fokussieren statt den gesamten Katalog zu rendern. So bleibt die Warmup-Dauer überschaubar und die Datenbank wird nicht durch das Vorwärmen selbst überlastet.
Redis im Cluster: gemeinsamer Cache für mehrere Server
Sobald ein Shop über mehr als einen Webserver läuft - etwa zur Lastverteilung oder für Ausfallsicherheit - wird ein gemeinsamer Cache zwingend. Würde jeder Server seinen eigenen Dateisystem-Cache führen, entstünden inkonsistente Zustände: Server A liefert eine aktualisierte Seite, Server B eine veraltete. Ein zentraler Redis löst das, weil alle Webserver auf denselben Speicher zugreifen. Genau deshalb ist Redis eine Grundvoraussetzung für Auto-Scaling bei Traffic-Spitzen.
Für den Cluster-Betrieb differenziert Shopware drei Datenkategorien (Shopware Docs): ephemere Daten (Caches, jederzeit regenerierbar), alternde Daten (Sessions, mit abnehmender Relevanz) und kritische Daten (Warenkörbe, Number Ranges, nicht regenerierbar). Für ephemere Daten ist keine Persistenz nötig; alternde und kritische Daten sollten dagegen über Snapshots (RDB) und Append-Only-Files (AOF) abgesichert werden, damit sie einen Neustart überstehen.
Ephemere Daten
HTTP- und Object-Cache. Jederzeit regenerierbar, keine Persistenz nötig, volatile-lru als Policy (Shopware Docs).
Alternde Daten
Sessions. Mit TTL versehen, allkeys-lru, abgesichert über RDB-Snapshots gegen Datenverlust (Shopware Docs).
Kritische Daten
Warenkorb, Number Ranges. Nicht regenerierbar - RDB + AOF Persistenz und volatile-lru zwingend (Shopware Docs).
Für Hochlastszenarien empfiehlt die Dokumentation außerdem Connection Pooling über den Parameter persistent=1 in der DSN, um den Verbindungs-Overhead zu reduzieren (Shopware Docs). Bei sehr großen Shops kann zusätzlich Redis-Cluster oder Replikation sinnvoll sein, um Lese-Last zu verteilen und Ausfallsicherheit zu erhöhen. Die konkrete Topologie hängt vom Traffic-Profil und den Verfügbarkeitsanforderungen ab - ein Punkt, der eng mit der Hosting-Architektur verzahnt ist.
Wichtig ist die Abgrenzung zwischen Redis und einem vorgelagerten Reverse Proxy: Redis cached innerhalb der Applikation, ein Reverse Proxy wie Varnish oder ein Edge-Cache an globalen Standorten liegt davor und liefert ganze Seiten aus, bevor die Anfrage die Webserver erreicht. Beide Schichten ergänzen sich: Der Edge-Cache fängt den Großteil anonymer Zugriffe ab, Redis beschleunigt die dynamischen Anfragen, die durchkommen. Bei mehreren Cache-Ebenen ist es entscheidend, die Invalidierung über alle Schichten hinweg zu synchronisieren, damit kein Layer veraltete Inhalte ausliefert.
Hit-Rate optimieren: den Cache messbar machen
Die wichtigste Kennzahl jedes Caches ist die Hit-Rate - der Anteil der Anfragen, die direkt aus dem Cache bedient werden. Als gesund gilt erfahrungsgemäß ein Wert über 80% (Kickbyte). Für statische Inhalte sind 95-99% erreichbar, für dynamische Inhalte realistischerweise 85-90% (Gcore). Je höher die Hit-Rate, desto seltener muss die Datenbank ran - und desto schneller und stabiler läuft der Shop unter Last.
Die Hit-Rate lässt sich direkt aus Redis auslesen. Der Befehl redis-cli INFO stats liefert die Werte keyspace_hits und keyspace_misses, aus denen sich die Trefferquote berechnen lässt. Sinkt die Hit-Rate, sind die häufigsten Ursachen: zu aggressive Invalidierung, zu kleiner maxmemory (sodass Einträge vorzeitig verdrängt werden) oder ein kalter Cache nach häufigen Deployments. Ein kontinuierliches Performance-Monitoring macht diese Effekte sichtbar.
# Hit-Rate aus Redis-Statistiken berechnen
redis-cli INFO stats | grep keyspace
# keyspace_hits:1840233
# keyspace_misses:96518
#
# Hit-Rate = hits / (hits + misses)
# = 1840233 / 1936751 = 95,0%Eine hohe Hit-Rate zahlt unmittelbar auf Geschäftskennzahlen ein. Analysen zeigen, dass eine Hit-Rate von rund 95% die Serverlast deutlich senkt und so auch während Lastspitzen nahezu sofortige Seitenauslieferung ermöglicht (SurferCloud). Der Weg dorthin führt über sinnvolle TTLs, ausreichend dimensionierten Speicher, eine maßvolle Invalidierungsstrategie und konsequentes Warmup - vier Stellschrauben, die zusammen die Wirkung des Caches bestimmen.
Die Wahl der TTL (Time to Live) verdient besondere Aufmerksamkeit. Eine zu kurze Lebensdauer lässt Einträge verfallen, bevor sie wiederverwendet werden - die Hit-Rate sinkt. Eine zu lange TTL riskiert veraltete Inhalte, solange keine gezielte Invalidierung greift. In der Praxis bewährt sich eine Staffelung: Statische Seitenbereiche und selten geänderte Stammdaten erhalten lange TTLs, häufig wechselnde Daten wie Lagerbestände kurze. Ergänzt wird das durch die maxmemory-Dimensionierung: Ist der Speicher zu knapp bemessen, verdrängt Redis Einträge vorzeitig und die Hit-Rate bricht ein - selbst bei perfekt gesetzten TTLs. Speichergröße, TTL und Invalidierung müssen daher zusammen betrachtet werden, idealerweise begleitet von einem fortlaufenden Monitoring der Kennzahlen.
Caching als Fundament für schnelle, skalierbare Shops
Die Datenlage ist eindeutig: Geschwindigkeit ist im E-Commerce direkt umsatzrelevant. 100 ms Verzögerung kosteten Amazon 1% Umsatz (Amazon), eine Sekunde mehr bis zu 7% weniger Conversions (Akamai), und schon eine Verbesserung der mobilen Ladezeit um 0,1 Sekunden steigerte die Conversion-Rate im Handel um 8,4% und den durchschnittlichen Bestellwert um 9,2% (Deloitte). Redis ist eines der wirkungsvollsten Werkzeuge, um diese Geschwindigkeit in Shopware zu erreichen.
Entscheidend ist die saubere Umsetzung: getrennte Redis-Instanzen je Datentyp, korrekt gesetzte Eviction-Policies und maxmemory-Grenzen, eine tag-basierte, verzögerte Invalidierung, automatisiertes Warmup nach jedem Deployment und ein Monitoring der Hit-Rate. Fehlkonfigurationen - eine gemeinsame Instanz, noeviction, fehlende Speichergrenzen - können mehr schaden als nutzen und im Extremfall den Shop ausfallen lassen (Kickbyte).
Caching wirkt kumulativ: Jede zusätzliche Cache-Schicht entlastet die darunterliegende, und jede Optimierung der Hit-Rate verstärkt den Effekt. Für wachsende Shops mit steigendem Sortiment und saisonalen Lastspitzen ist eine durchdachte Redis-Architektur daher kein optionales Extra, sondern die Basis für schnelle Seiten, einen stabilen Checkout und eine reibungslose Customer Journey. Als Agentur mit Schwerpunkt auf Shopware und performantem Hosting unterstützen wir Sie bei Konfiguration, Cluster-Betrieb und der laufenden Optimierung Ihrer Caching-Schicht.
Dieser Artikel basiert auf Daten und Empfehlungen aus: Shopware Documentation (Cache-Architektur, Eviction-Policies, getrennte Instanzen, verzögerte Invalidierung, Warmup), Redis Documentation (Durchsatz und Latenz-Benchmarks), Amazon (100-ms-Umsatzeffekt), Akamai (Conversion-Effekt bei Verzögerung), Deloitte / Google (Milliseconds Make Millions, mobile Ladezeit und Conversion), AWS (In-Memory- gegenüber Datenbank-Lesegeschwindigkeit), Kickbyte (Redis-Konfigurationsfehler in Shopware), Gcore und SurferCloud (Cache-Hit-Ratio-Benchmarks), ma.ttias.be (PHP-Session-Locking). Die genannten Zahlen können je nach Hardware, Konfiguration und Traffic-Profil variieren.
Häufig gestellte Fragen zu Redis-Caching in Shopware
Nein. Redis ist eine schnelle Zwischenschicht, nicht die Quelle der Wahrheit. Die MySQL- bzw. MariaDB-Datenbank bleibt führend; Redis fängt wiederkehrende Lesezugriffe ab und liefert sie bei einem Cache-Hit im Sub-Millisekunden-Bereich (Redis Docs). Bei einem Cache-Miss fällt die Anfrage auf die Datenbank zurück, das Ergebnis wird berechnet und anschließend in Redis abgelegt.
Das hängt stark von Ausgangslage, Hardware und Konfiguration ab. In-Memory-Caching kann Ladezeiten erfahrungsgemäß um bis zu 40% verkürzen (Hosted Power), und Leseoperationen sind im Vergleich zur Datenbank bis zu 80-mal schneller (AWS). Den größten Effekt liefert in der Regel der HTTP-Cache für häufig aufgerufene Kategorie- und Produktseiten.
Aktuelle Redis-Versionen können pro Instanz nur eine Eviction-Policy anwenden (Shopware Docs). Eine gemeinsame Instanz führt zu Ressourcenkonkurrenz: Greift die Eviction, können aktive Warenkörbe oder Sessions gelöscht werden und Kunden verlieren im Checkout ihre Artikel (Kickbyte). Getrennte Instanzen erlauben je Datentyp die passende Policy und Persistenz.
Für ephemere Caches (HTTP, Object) eignen sich volatile-lru oder allkeys-lru. Für kritische Daten wie Number Ranges schützt volatile-lru Einträge ohne TTL vor dem Löschen. Die Policy noeviction sollte für Caches vermieden werden, weil Redis dann Schreibzugriffe ablehnt, sobald maxmemory erreicht ist - das kann zu Shop-Fehlern führen (Kickbyte).
Über redis-cli INFO stats lassen sich keyspace_hits und keyspace_misses auslesen; die Hit-Rate ergibt sich als hits geteilt durch (hits plus misses). Als gesund gilt erfahrungsgemäß ein Wert über 80% (Kickbyte), für statische Inhalte sind 95-99% erreichbar, für dynamische Inhalte realistischerweise 85-90% (Gcore).
Nach einem Deployment oder einer Invalidierung ist der Cache zunächst kalt, sodass die ersten Besucher einen Cache-Miss erleben. Ein automatisiertes Warmup über bin/console cache:warmup oder einen Sitemap-Crawler rendert die wichtigsten Seiten vorab und schreibt sie in den Cache (Shopware Docs), sodass produktive Besucher von Beginn an auf warme Caches treffen.