Redis als Session- und Cache-Backend in Magento 2 richtig dimensionieren

1. Einordnung: Redis als Session- und Cache-Backend

Redis uebernimmt in einer typischen Magento 2 Installation zwei grundlegend verschiedene Aufgaben, die in der Praxis oft ueber denselben Server laufen, obwohl sie vollkommen unterschiedliche Zugriffsmuster erzeugen. Als Session-Storage speichert Redis pro Besucher einen kleinen, aber haeufig gelesenen und geschriebenen Datensatz: Warenkorb-Referenz, Kundendaten-Flags, CSRF-Token und Formular-Keys. Als Cache-Backend ueber Cm_Cache_Backend_Redis speichert derselbe Prozess dagegen deutlich groessere, seltener geschriebene, aber intensiv gelesene Bloecke: kompilierte Layout-Daten, Blockausgaben und bei aktiviertem Full Page Cache ganze gerenderte HTML-Seiten.

Der Unterschied zeigt sich am deutlichsten in der Schreiblast. Eine Session wird bei praktisch jedem Request aktualisiert, weil Magento den Zugriffszeitpunkt und haeufig auch CSRF-Formular-Keys neu schreibt. Das Cache-Backend dagegen wird nur bei einer Invalidierung neu beschrieben, etwa nach einer Produktaenderung, und ansonsten fast ausschliesslich gelesen. Wer Redis nur als eine homogene Instanz behandelt, uebersieht, dass Session-Traffic latenzkritisch und schreiblastig ist, waehrend Cache-Traffic durchsatzorientiert und leselastig ist.

Diese Unterscheidung ist keine akademische Feinheit, sie bestimmt direkt die Dimensionierung, die maxmemory-policy und die Persistence-Strategie. Ein Redis, der fuer Sessions und Cache gemeinsam konfiguriert ist, neigt dazu, im Zweifel die falschen Keys zu verdraengen: Wird eine Session unter Speicherdruck evictet, verliert ein Kunde seinen Warenkorb oder wird ungewollt ausgeloggt. Wird dagegen ein Cache-Eintrag evictet, kostet das lediglich einen Rebuild. Die folgenden Abschnitte zeigen, wie sich die Instanzen fuer beide Rollen sauber dimensionieren und trennen lassen.

2. Speicherbedarf berechnen: Sessions, TTL und gleichzeitige Nutzer

Die Kapazitaetsplanung fuer Redis als Session-Backend beginnt mit drei Groessen: der durchschnittlichen Groesse einer serialisierten Session, der Session-TTL und der Anzahl gleichzeitig aktiver Sessions waehrend der Lastspitze. Eine durchschnittliche Magento-Session belegt je nach Anzahl der Warenkorb-Artikel, aktivierten Modulen und gespeicherten Formular-Keys zwischen 4 und 15 KB. Wer diese Groesse nicht misst, sondern schaetzt, dimensioniert entweder deutlich zu grosszuegig oder laeuft bei unerwarteten Lastspitzen wie Sale-Aktionen in Produktionsprobleme.

Der zweite Faktor ist die TTL, gesteuert ueber max_lifetime in der Session-Konfiguration. Eine laengere TTL bedeutet mehr gleichzeitig gespeicherte Sessions, insbesondere bei B2B-Shops mit langen Entscheidungszyklen. Die Kapazitaetsformel lautet vereinfacht: benoetigter Speicher gleich gleichzeitige Sessions mal durchschnittliche Session-Groesse mal ein Fragmentierungsfaktor von etwa 1.3, um interne Speicherverwaltung und eine Wachstumsreserve zu beruecksichtigen. Bei 50.000 gleichzeitigen Sessions mit durchschnittlich 8 KB ergibt das ungefaehr 520 MB reinen Datenspeicher, in der Praxis sollte man auf mindestens 750 MB bis 1 GB dimensionieren.

Statt mit Schaetzwerten zu planen, liefern die folgenden redis-cli Befehle die realen Messwerte fuer die eigene Instanz:

# Anzahl der Keys in der Session-Datenbank ermitteln
redis-cli -n 2 DBSIZE

# Stichprobe: Speicherverbrauch einzelner Session-Keys pruefen
redis-cli -n 2 --scan --pattern 'sess_*' | head -20 | while read -r key; do
  redis-cli -n 2 MEMORY USAGE "$key"
done

# Gesamten Speicherverbrauch der Session-Instanz anzeigen
redis-cli -n 2 INFO memory | grep used_memory_human

# Kapazitaetsformel:
# benoetigter_RAM_KB = gleichzeitige_Sessions * durchschnittliche_Groesse_KB * Fragmentierungsfaktor
# Beispiel: 50.000 gleichzeitige Sessions, 8 KB Durchschnitt, Faktor 1.3
echo "$((50000 * 8 * 13 / 10)) KB geschaetzter Speicherbedarf"

DBSIZE liefert die Anzahl der Keys in der ausgewaehlten Datenbank, waehrend MEMORY USAGE den tatsaechlichen Speicherverbrauch eines einzelnen Keys inklusive internem Overhead zurueckgibt. Wer diese Werte ueber mehrere Stichproben mittelt und mit der Anzahl aktiver Sessions aus dem Access-Log multipliziert, erhaelt eine belastbare Kapazitaetsplanung statt einer Bauchgefuehl-Schaetzung.

3. env.php Konfiguration: getrennte Redis-Instanzen fuer Session, Cache und Page Cache

Magento erlaubt es, fuer Cache, Page Cache und Session jeweils eigene Verbindungsparameter in der env.php zu hinterlegen. Diese Trennung sollte im Idealfall nicht nur ueber unterschiedliche Datenbanknummern innerhalb derselben Redis-Instanz erfolgen, sondern ueber tatsaechlich getrennte Prozesse mit eigenem Port und eigener maxmemory-Grenze. Der Grund: Eine gemeinsame maxmemory-Grenze fuer Session und Cache fuehrt dazu, dass ein Cache-Ansturm nach einem Deploy die Session-Daten unter Eviction-Druck setzt, und umgekehrt.

In der Praxis hat sich ein Aufbau mit drei Instanzen bewaehrt: eine fuer den Default-Cache und Konfigurations-Cache, eine fuer den Full Page Cache mit typischerweise deutlich groesseren Werten, und eine dedizierte Instanz ausschliesslich fuer Sessions. Jede Instanz bekommt eigenen Port, eigenes maxmemory und eine auf ihr Zugriffsmuster abgestimmte Eviction-Policy.

// app/etc/env.php - excerpt: separate Redis instances for cache, page_cache and session
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
                'compress_data' => '1',
                'compression_lib' => 'gzip',
            ],
        ],
        'page_cache' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6380',
                'database' => '0',
                'compress_data' => '0',
            ],
        ],
    ],
],
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6381',
        'database' => '0',
        'compression_threshold' => '2048',
        'compression_library' => 'gzip',
    ],
],

compress_data und compression_lib reduzieren den Speicherbedarf im Cache-Backend, kosten aber CPU-Zyklen bei jedem Lese- und Schreibzugriff. Fuer die Session-Instanz ist compression_threshold sinnvoller als eine pauschale Kompression, weil kleine Sessions ohnehin kaum Kompressionsgewinn bringen, jede Kompression aber Latenz addiert, die bei Session-Zugriffen direkt in die Time-to-First-Byte einfliesst.

4. redis.conf Tuning: maxmemory, Eviction-Policy und Persistence im Vergleich

Die maxmemory-policy entscheidet, welche Keys Redis entfernt, wenn die maxmemory-Grenze erreicht ist. Fuer die Cache-Instanz ist allkeys-lru meist die richtige Wahl, weil praktisch alle gespeicherten Keys gleichwertige Cache-Eintraege sind und der am laengsten nicht genutzte Eintrag ohne Risiko verdraengt werden kann, ein Cache-Rebuild kostet lediglich etwas CPU-Zeit. Fuer die Session-Instanz ist volatile-lru vorzuziehen, weil Magento jede Session mit einer TTL versieht und dadurch bevorzugt bereits ablaufnahe Sessions entfernt werden, statt aktiv genutzte Sessions willkuerlich zu verdraengen.

Die zweite zentrale Entscheidung betrifft Persistence. RDB-Snapshots erzeugen in konfigurierbaren Intervallen ein vollstaendiges Speicherabbild, was bei grossen Datenmengen zu kurzen Latenzspitzen durch den fork-Systemaufruf fuehrt. AOF protokolliert dagegen jeden Schreibbefehl und ermoeglicht eine deutlich feingranularere Wiederherstellung, kostet aber kontinuierlich mehr I/O. Fuer eine reine Cache-Instanz, deren Inhalt jederzeit aus der Datenbank neu aufgebaut werden kann, ist Persistence meist komplett verzichtbar, save "" deaktiviert RDB-Snapshots vollstaendig und spart die damit verbundenen Latenzspitzen.

Fuer die Session-Instanz sieht die Abwaegung anders aus. Ohne jede Persistence fuehrt ein Neustart, etwa nach einem Server-Patch, zum sofortigen Verlust aller aktiven Sessions und damit zu massenhaften ungewollten Logouts und leeren Warenkoerben. AOF mit appendfsync everysec ist hier meist der bessere Kompromiss: Im Fehlerfall geht maximal eine Sekunde an Session-Schreibzugriffen verloren, waehrend die kontinuierliche I/O-Last durch die Batch-Synchronisation begrenzt bleibt.

# redis-cache.conf - dedicated cache and page_cache instance (port 6379/6380)
maxmemory 2gb
maxmemory-policy allkeys-lru
save ""
appendonly no
tcp-keepalive 300
timeout 0

# redis-session.conf - dedicated session instance (port 6381)
maxmemory 1gb
maxmemory-policy volatile-lru
save ""
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
tcp-keepalive 300
timeout 0

5. Hochverfuegbarkeit: Redis Sentinel vs. Redis Cluster fuer Magento

Sobald ein einzelner Redis-Prozess zum Single Point of Failure wird, stellt sich die Frage nach Redis Sentinel oder Redis Cluster. Sentinel ueberwacht eine Gruppe von Redis-Instanzen im Master-Replica-Verbund, erkennt den Ausfall des Masters automatisch und fuehrt ein Failover auf eine Replica durch. Fuer Magento ist das die praxistauglichere Loesung, weil sowohl das Session-Handler-Modul als auch Cm_Cache_Backend_Redis Sentinel-Verbindungen unterstuetzen und Magento einfach die Sentinel-Endpunkte statt eines einzelnen Hosts eintraegt.

Redis Cluster verteilt Daten dagegen ueber mehrere Shards mit Hash-Slot-Partitionierung und skaliert horizontal ueber den Speicher eines einzelnen Servers hinaus. Das klingt zunaechst attraktiv fuer sehr grosse Installationen, allerdings unterstuetzt Cm_Cache_Backend_Redis, das Magento fuer das Cache-Backend nutzt, kein zuverlaessiges natives Cluster-Slotting fuer Multi-Key-Operationen wie das Tag-basierte Invalidieren von Cache-Eintraegen. In der Praxis bedeutet das: Cluster fuer das Magento-Cache-Backend bringt mehr Komplexitaet als Nutzen, solange eine einzelne gut dimensionierte Instanz oder ein Sentinel-Verbund ausreicht.

Fuer sehr grosse Multi-Store-Installationen mit mehreren hundert Gigabyte Cache-Daten kann eine Aufteilung ueber mehrere unabhaengige Instanzen pro Website oder Store-Gruppe, statt eines echten Clusters, meist die robustere und einfacher zu betreibende Loesung sein. Die Entscheidung zwischen Sentinel und Cluster sollte daher weniger von der reinen Datenmenge, sondern vom tatsaechlichen Support in Magentos Redis-Adaptern abhaengen.

6. Session-Locking und Race Conditions vermeiden

Wenn ein Browser mehrere parallele Requests fuer denselben Nutzer absetzt, etwa durch AJAX-Aufrufe fuer Warenkorb-Widgets oder gleichzeitig geladene Bloecke, greifen mehrere PHP-Prozesse gleichzeitig auf dieselbe Session zu. Ohne Locking ueberschreibt der zuletzt schreibende Prozess die Aenderungen der anderen, eine klassische Race Condition, die im Warenkorb zu verschwundenen Artikeln fuehren kann. Magentos Redis-Session-Handler implementiert dafuer ein eigenes Locking-Verfahren oberhalb der nativen Redis-Primitiven.

Die wichtigsten Parameter dafuer sind min_lock_lifetime, max_lock_lifetime, max_concurrent_locks und break_after_frontend. min_lock_lifetime verhindert, dass ein Lock sofort nach dem Setzen wieder freigegeben wird, waehrend max_lock_lifetime eine Obergrenze definiert, nach der ein Lock zwangsweise als abgelaufen gilt, um verwaiste Locks bei abgestuerzten Prozessen zu vermeiden. break_after_frontend gibt an, nach wie vielen Sekunden ein wartender Frontend-Request das Warten auf einen Lock abbricht und stattdessen ohne Lock fortfaehrt, um lange Ladezeiten durch aufeinander wartende Requests zu verhindern.

disable_locking deaktiviert das gesamte Locking-Verfahren und sollte praktisch nie global gesetzt werden, weil damit genau die Race Conditions wieder moeglich werden, die das Locking verhindern soll. Sinnvoll ist disable_locking hoechstens fuer spezifische, klar isolierte AJAX-Endpunkte, die selbst keine schreibenden Session-Zugriffe durchfuehren, etwa reine Lesezugriffe fuer ein Tracking-Skript.

// app/etc/env.php - session locking configuration against race conditions
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6381',
        'database' => '0',
        'max_lifetime' => '2592000',
        'min_lifetime' => '60',
        'disable_locking' => '0',
        'min_lock_lifetime' => '10',
        'max_lock_lifetime' => '35',
        'max_concurrent_locks' => '6',
        'break_after_frontend' => '5',
        'break_after_adminhtml' => '30',
        'first_lifetime' => '600',
        'bot_first_lifetime' => '60',
        'bot_lifetime' => '7200',
        'log_level' => '1',
    ],
],

7. Monitoring: Speicherverbrauch, Eviction-Rate und Fruehwarnsignale

Redis bietet ueber den INFO-Befehl detaillierte Betriebsmetriken, die weit ueber den reinen Speicherverbrauch hinausgehen. Der Abschnitt memory liefert used_memory_human fuer den aktuellen Verbrauch und mem_fragmentation_ratio, ein Wert deutlich ueber 1.5 deutet auf Speicherfragmentierung hin, die durch haeufige Groessenaenderungen von Keys entsteht und mit dem aktivierbaren Defragmentierungs-Feature activedefrag adressiert werden kann.

Die wichtigste Fruehwarnmetrik ist evicted_keys aus dem Abschnitt stats. Steigt dieser Zaehler kontinuierlich an, verdraengt das System aktiv Keys, weil maxmemory erreicht ist, was bei der Cache-Instanz zu erhoehten Cache-Miss-Raten und bei der Session-Instanz im schlimmsten Fall zu verlorenen Nutzersessions fuehrt. Ergaenzend zeigt das Verhaeltnis von keyspace_hits zu keyspace_misses, wie effektiv der Cache tatsaechlich arbeitet, eine sinkende Hit-Rate ist oft das erste sichtbare Symptom eines zu knapp bemessenen maxmemory.

# Live-Statistik: Operationen pro Sekunde, Speicher, Client-Verbindungen
redis-cli -p 6379 --stat

# Speicherinformationen inkl. Fragmentierung
redis-cli -p 6379 INFO memory | grep -E 'used_memory_human|mem_fragmentation_ratio|maxmemory_human'

# Eviction- und Hit-Rate als Fruehwarnsignal
redis-cli -p 6379 INFO stats | grep -E 'evicted_keys|expired_keys|keyspace_hits|keyspace_misses'

# Slowlog fuer Befehle ueber einem Schwellenwert (Mikrosekunden)
redis-cli -p 6379 CONFIG SET slowlog-log-slower-than 10000
redis-cli -p 6379 SLOWLOG GET 10

Fuer die laufende Ueberwachung eignet sich redis-cli --stat, das kontinuierlich Kennzahlen in einer Zeile pro Intervall ausgibt, ideal fuer eine schnelle Diagnose direkt auf dem Server. Fuer produktives Monitoring sollten diese Metriken jedoch zusaetzlich in ein Monitoring-System wie Prometheus mit dem redis_exporter exportiert werden, damit Schwellenwert-Alarme automatisch ausloesen, bevor Nutzer die Auswirkungen einer zu knappen Dimensionierung im Frontend bemerken.

8. Typische Fehler bei Redis fuer Session und Cache

Der haeufigste Fehler ist eine gemeinsame Redis-Datenbank fuer Session und Cache ohne Trennung von maxmemory und Eviction-Policy. Sobald ein grosser Cache-Rebuild nach einem Deploy die Speichergrenze der gemeinsamen Instanz erreicht, verdraengt das System je nach Policy auch Session-Keys, was zu einer Welle ungewollter Logouts direkt nach jedem Deployment fuehrt, ein Muster, das in Produktions-Logs oft erst nach Wochen als Kapazitaetsproblem erkannt wird, weil die Symptome zunaechst wie ein Anwendungsfehler aussehen.

Ein zweiter verbreiteter Fehler ist eine fehlende oder falsch gewaehlte Persistence-Strategie. Wird fuer die Session-Instanz komplett auf Persistence verzichtet, weil das vermeintlich Performance spart, fuehrt jeder geplante oder ungeplante Neustart zu einem kompletten Session-Verlust. Umgekehrt kostet eine zu aggressive RDB-Snapshot-Konfiguration mit kurzen Intervallen auf einer stark schreibenden Session-Instanz spuerbare Latenzspitzen durch den fork-Aufruf, gerade bei grossen Datenmengen im Arbeitsspeicher.

Ein dritter Fehler betrifft das Timeout-Handling der Redis-Verbindung selbst. Ein zu niedriger connect_timeout oder read_timeout in der env.php fuehrt bei kurzen Netzwerk-Spitzen zu haeufigen, aber vermeidbaren Fehlern, waehrend ein zu hoher Timeout dazu fuehrt, dass ein tatsaechlich ausgefallener Server PHP-Prozesse minutenlang blockiert, statt schnell einen Fehler zurueckzugeben. Ein Timeout im Bereich von 2.5 bis 5 Sekunden mit aktivierter Retry-Logik ist fuer die meisten Setups ein sinnvoller Ausgangspunkt.

9. Redis-Konfigurationen fuer unterschiedliche Shop-Groessen im Vergleich

Wie viel RAM, welche Eviction-Policy und welche Persistence-Strategie fuer Redis sinnvoll sind, haengt stark von der Shop-Groesse und dem Traffic-Muster ab. Die folgende Uebersicht zeigt grobe Richtwerte fuer typische Konstellationen, jeweils getrennt fuer Session- und Cache-Instanz.

Diese Werte sind Ausgangspunkte fuer die eigene Kapazitaetsplanung, keine festen Vorgaben. Wer die in Abschnitt 2 gezeigten redis-cli Befehle regelmaessig gegen die eigene Installation laufen laesst, kann die Tabellenwerte innerhalb weniger Wochen durch reale Messwerte ersetzen und die Instanzen darauf anpassen.

10. Zusammenfassung

Die wichtigste Erkenntnis rund um Redis als Session- und Cache-Backend in Magento 2 lautet: Beide Rollen brauchen getrennte Instanzen, getrennte maxmemory-Grenzen und getrennte Eviction-Policies. Der Speicherbedarf fuer Sessions laesst sich aus durchschnittlicher Session-Groesse, TTL und gleichzeitigen Nutzern berechnen, statt geschaetzt zu werden. env.php und redis.conf sollten fuer Cache, Page Cache und Session jeweils eigene Ports und eine auf das Zugriffsmuster abgestimmte Persistence-Strategie definieren, allkeys-lru ohne Persistence fuer den Cache, volatile-lru mit AOF everysec fuer Sessions.

Session-Locking mit sinnvoll gewaehlten min_lock_lifetime- und break_after_frontend-Werten verhindert Race Conditions bei parallelen Requests, waehrend Redis Sentinel fuer die meisten Magento-Installationen die praxistauglichere Hochverfuegbarkeitsloesung gegenueber Cluster ist. Kontinuierliches Monitoring von evicted_keys, mem_fragmentation_ratio und der Hit-Rate macht eine zu knappe Dimensionierung sichtbar, bevor Kunden sie im Frontend als verschwundenen Warenkorb oder ungewollten Logout erleben.

11. FAQ: Redis als Session- und Cache-Backend in Magento 2