Memory-Sizing fuer Redis in Magento-Shops richtig planen

1. Warum Memory-Sizing fuer Redis kritisch ist

Redis haelt saemtliche Daten im Arbeitsspeicher, was die Grundlage seiner Geschwindigkeit ist, aber gleichzeitig bedeutet, dass RAM die einzige harte Grenze der Kapazitaet darstellt. Anders als bei einem dateibasierten Cache, der einfach auf Disk weiterwaechst, fuehrt ein zu knapp bemessener Redis-Server entweder zu aggressiver Eviction, die die Trefferquote ruiniert, oder, ohne konfigurierte maxmemory-Grenze, zu einem Out-of-Memory-Zustand, der den gesamten Redis-Prozess zum Absturz bringen kann.

Gutes Memory-Sizing ist deshalb keine einmalige Schaetzung beim Projektstart, sondern ein fortlaufender Prozess, der Katalog-Wachstum, saisonale Traffic-Spitzen und neue Features wie zusaetzliche Kundengruppen oder Sprachversionen beruecksichtigt. Ein Shop, der beim Launch mit 2 GB RAM fuer Redis auskommt, kann nach einem Jahr organischen Wachstums bereits 8 GB benoetigen, ohne dass sich an der grundsaetzlichen Architektur etwas geaendert hat.

Dieser Artikel behandelt Memory-Sizing getrennt fuer die drei Hauptrollen Cache, Session und Full-Page-Cache, weil jede Rolle ein grundlegend anderes Wachstumsmuster hat: Cache-Speicherbedarf skaliert mit der Katalog-Groesse, Session-Speicherbedarf mit gleichzeitigem Traffic, und FPC-Speicherbedarf mit der Kombination aus Seitenanzahl und Kundengruppen-Varianten.

2. Cache-Speicherbedarf abschaetzen

Der allgemeine Magento-Cache umfasst Konfiguration, Layout-XML, Block-HTML und EAV-Metadaten. Der groesste variable Anteil ist typischerweise der Block-HTML-Cache, dessen Groesse direkt mit der Anzahl der Produkte und Kategorien waechst. Als Faustregel laesst sich pro Produkt mit 2 bis 5 Kilobyte an Cache-Daten rechnen, abhaengig von der Komplexitaet des Themes und der Anzahl gerenderter Bloecke pro Produktseite.

Fuer einen Katalog mit 50.000 Produkten ergibt das ueberschlaegig 100 bis 250 Megabyte an reinem Block-HTML-Cache, zuzueglich Konfigurations- und Layout-Cache, der meist im niedrigen zweistelligen Megabyte-Bereich liegt und kaum mit der Katalog-Groesse skaliert. Wichtig fuer realistisches Memory-Sizing: Diese Schaetzung gilt pro Store View und Sprachversion, ein Shop mit drei Sprachen multipliziert den Cache-Speicherbedarf entsprechend, weil jede Sprachversion eigene gecachte Bloecke erzeugt.

# Measure actual average size of cache entries in the running instance
redis-cli -n 0 DBSIZE
redis-cli -n 0 INFO memory | grep used_memory_human

# Sample a set of cache keys and inspect their size distribution
redis-cli -n 0 --bigkeys

# Estimate memory per key: total used memory divided by key count
redis-cli -n 0 MEMORY USAGE "zc:k:SAMPLE_KEY_ID"

3. Session-Speicherbedarf abschaetzen

Session-Speicherbedarf folgt einem anderen Muster als Cache: Er skaliert nicht mit der Katalog-Groesse, sondern mit der Anzahl gleichzeitig aktiver Besucher. Eine typische Magento-Session belegt zwischen 2 und 10 Kilobyte, abhaengig davon, wie viele Daten in der Session gespeichert werden, etwa Warenkorb-Inhalte, zuletzt angesehene Produkte oder Formular-Zwischenstaende bei Multi-Step-Checkouts.

Fuer die Kapazitaetsplanung ist die relevante Zahl nicht der taegliche Gesamttraffic, sondern die Anzahl gleichzeitig aktiver Sessions zur Spitzenlastzeit. Ein Shop mit 500 gleichzeitigen Besuchern zur Stosszeit und durchschnittlich 5 Kilobyte pro Session benoetigt etwa 2,5 Megabyte an reinem Sessionspeicher, ein vergleichsweise kleiner Anteil am Gesamt-Memory-Sizing. Bei Traffic-Spitzen durch Kampagnen oder Sale-Events kann sich die Anzahl gleichzeitiger Sessions jedoch leicht verzehnfachen, was bei der Dimensionierung explizit eingeplant werden sollte, statt nur den Normalbetrieb zugrunde zu legen.

4. FPC-Speicherbedarf abschaetzen

Der Full-Page-Cache hat den komplexesten Speicherbedarf der drei Rollen, weil er nicht nur mit der Seitenanzahl, sondern auch mit der Anzahl an Varianten pro Seite skaliert. Jede Kombination aus Seite, Kundengruppe, Waehrung und Store View erzeugt einen eigenen Cache-Eintrag. Ein Shop mit 3 Kundengruppen, 2 Waehrungen und 2 Store Views multipliziert die effektive Anzahl an Cache-Eintraegen mit dem Faktor 12 gegenueber einem Shop ohne diese Varianten.

Eine vollstaendig gerenderte Produktseite als HTML liegt typischerweise zwischen 30 und 150 Kilobyte, abhaengig von Theme-Komplexitaet und eingebetteten Bloecken wie Cross-Selling-Widgets. Fuer Memory-Sizing-Zwecke multipliziert man die Anzahl cachbarer Seiten (Produkte plus Kategorien plus CMS-Seiten) mit der durchschnittlichen HTML-Groesse und dem Varianten-Faktor. Bei 50.000 Produkten, 500 Kategorien, durchschnittlich 60 Kilobyte pro Seite und einem Varianten-Faktor von 4 ergibt das ueberschlaegig 12 Gigabyte an potenziellem FPC-Speicherbedarf, sofern jede Variante tatsaechlich besucht und gecacht wird.

<?php
// app/etc/env.php - page_cache with maxmemory-aware sizing comment
// Estimated FPC memory need: products x categories x variant_factor x avg_html_size
// Example: 50000 x 1 + 500 x 1 = 50500 pages, x4 variants x 60 KB ~= 12 GB potential
'cache' => [
    'frontend' => [
        'page_cache' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
                'compress_data' => '1',
                'compress_threshold' => '10240',
                'compression_lib' => 'gzip',
            ],
        ],
    ],
],

5. maxmemory konfigurieren und Eviction verstehen

In der Praxis ist es selten sinnvoll, Redis fuer den theoretischen Maximalbedarf zu dimensionieren, bei dem jede moegliche FPC-Variante gleichzeitig gecacht ist. Realistisches Memory-Sizing beruecksichtigt, dass nur ein Bruchteil aller theoretisch moeglichen Seiten tatsaechlich regelmaessig besucht wird, das sogenannte Pareto-Prinzip: Meist erzeugen 20 Prozent der Produkte 80 Prozent des Traffics und damit auch 80 Prozent der tatsaechlich gecachten Eintraege.

Die maxmemory-Direktive in redis.conf setzt eine harte Obergrenze, ab der die konfigurierte maxmemory-policy greift. Fuer den FPC ist allkeys-lru sinnvoll, weil selten besuchte Seiten automatisch aus dem Cache verdraengt werden, waehrend haeufig besuchte Seiten warm bleiben. Ohne maxmemory-Grenze waechst Redis unbegrenzt weiter, bis der Server-RAM erschoepft ist, was zu einem harten Absturz statt einer kontrollierten Eviction fuehrt.

# redis.conf snippet: hard memory ceiling plus eviction policy for the FPC instance
maxmemory 4gb
maxmemory-policy allkeys-lru

# Apply and verify at runtime without a restart
redis-cli CONFIG SET maxmemory 4gb
redis-cli CONFIG GET maxmemory

6. Wachstum ueberwachen: INFO memory und --bigkeys

Einmaliges Memory-Sizing beim Projektstart reicht nicht aus, weil sich Kataloggroesse, Traffic und Nutzungsmuster kontinuierlich veraendern. redis-cli INFO memory liefert die zentralen Kennzahlen: used_memory_human zeigt den aktuellen Verbrauch, used_memory_peak_human den bisherigen Hoechststand, und mem_fragmentation_ratio zeigt, wie effizient Redis den zugewiesenen Speicher tatsaechlich nutzt.

Ein systematisches Monitoring erfasst diese Werte regelmaessig, etwa taeglich, und visualisiert den Trend ueber Wochen und Monate. Ein linear wachsender used_memory_human-Wert ueber mehrere Monate ist ein klares Signal, dass die naechste Kapazitaetsplanung faellig ist, lange bevor die maxmemory-Grenze tatsaechlich erreicht wird. redis-cli --bigkeys ergaenzt dieses Bild, indem es ungewoehnlich grosse einzelne Eintraege aufspuert, die auf fehlende Kompression oder ineffizientes Caching einzelner Seiten hindeuten koennen.

# Core memory metrics for ongoing capacity monitoring
redis-cli INFO memory | grep -E "used_memory_human|used_memory_peak_human|mem_fragmentation_ratio"

# Historical tracking example: append daily snapshot to a monitoring log
echo "$(date +%F) $(redis-cli INFO memory | grep used_memory_human:)" >> /var/log/redis-memory-trend.log

# Find the largest keys across all sampled types
redis-cli --bigkeys -i 0.1

# Check eviction counter to correlate with hit rate drops
redis-cli INFO stats | grep evicted_keys

# Compare hit rate over time (hits vs misses ratio)
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"

7. Kapazitaetsplanung: Formel und Praxisbeispiel

Eine praktikable Formel fuer initiales Memory-Sizing kombiniert die drei Rollen additiv, mit einem Sicherheitspuffer fuer Fragmentierung und ungeplantes Wachstum: Gesamtspeicher gleich Cache-Bedarf plus Session-Bedarf plus realistischer FPC-Bedarf (nicht der theoretische Maximalwert), multipliziert mit einem Faktor 1,5 bis 2 als Puffer. Der Puffer beruecksichtigt sowohl Redis-interne Speicher-Fragmentierung als auch unvorhergesehene Traffic-Spitzen.

Praxisbeispiel: Ein mittelgrosser Shop mit 20.000 Produkten, 200 gleichzeitigen Sitzungen zur Spitzenlast und einem realistischen FPC-Anteil von 15 Prozent der theoretisch moeglichen Seiten kommt auf etwa 60 Megabyte Cache, 1 Megabyte Session und 1,8 Gigabyte realistischen FPC-Bedarf. Mit Puffer-Faktor 1,75 ergibt das rund 3,3 Gigabyte empfohlene maxmemory-Grenze, gerundet auf 4 Gigabyte fuer den naechsten sinnvollen Instanz-Grössenschritt.

8. Warnsignale fuer zu knapp bemessenen Speicher

Das deutlichste Warnsignal fuer unzureichendes Memory-Sizing ist eine sinkende Trefferquote trotz gleichbleibendem oder wachsendem Traffic, sichtbar am Verhaeltnis von keyspace_hits zu keyspace_misses in redis-cli INFO stats. Sinkt diese Quote spuerbar, obwohl sich am Nutzerverhalten nichts geaendert hat, deutet das auf aggressive Eviction durch eine zu knappe maxmemory-Grenze hin.

Ein zweites Warnsignal ist ein hoher Wert bei evicted_keys in INFO stats, der direkt zaehlt, wie viele Schluessel wegen Speichermangel entfernt wurden. Ein staendig wachsender Wert bei gleichzeitig konstantem Traffic zeigt, dass die aktuelle Speicherzuweisung nicht mehr zum tatsaechlichen Bedarf passt und eine Kapazitaetserweiterung ansteht, bevor Nutzer die Verlangsamung tatsaechlich spueren.

# Quick health check script: hit rate and eviction pressure in one call
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses|evicted_keys"

# Alert threshold example: warn if evicted_keys grows between two snapshots
redis-cli INFO stats | grep evicted_keys >> /var/log/redis-eviction-trend.log

9. Sizing-Szenarien nach Shop-Groesse im Vergleich

Die folgende Tabelle bietet grobe Richtwerte fuer typische Shop-Groessen als Ausgangspunkt fuer eigene, detailliertere Berechnungen.

Diese Richtwerte dienen als grobe Orientierung und ersetzen keine individuelle Berechnung anhand der in diesem Artikel beschriebenen Formel. Faktoren wie Anzahl Kundengruppen, Sprachversionen und tatsaechlich genutzter FPC-Anteil koennen den realen Bedarf innerhalb einer Kategorie um den Faktor 2 bis 3 verschieben, weshalb kontinuierliches Monitoring wichtiger ist als eine einmalige, statische Einschaetzung.

10. Zusammenfassung

Fundiertes Memory-Sizing fuer Redis in Magento erfordert, Cache, Session und Full-Page-Cache getrennt zu betrachten, weil jede Rolle nach unterschiedlichen Treibern waechst: Cache mit der Katalog-Groesse, Session mit gleichzeitigem Traffic, FPC mit der Kombination aus Seitenanzahl und Kundengruppen-Varianten. Eine additive Formel mit realistischem, nicht theoretischem FPC-Anteil und einem Sicherheitspuffer von 1,5 bis 2 liefert einen belastbaren Ausgangswert fuer die maxmemory-Konfiguration.

Kontinuierliches Monitoring ueber INFO memory, evicted_keys und die Trefferquote ist unverzichtbar, weil sich Katalog und Traffic staendig veraendern. Wer Memory-Sizing als einmalige Aufgabe beim Projektstart behandelt statt als fortlaufenden Prozess, riskiert schleichende Performance-Verschlechterung, die oft erst bemerkt wird, wenn Kunden bereits abspringen.

11. FAQ: Memory-Sizing fuer Redis in Magento-Shops