Planning Redis Memory Sizing for Magento Shops Correctly

1. Why memory sizing for Redis is critical

Redis keeps all data in memory, which is the foundation of its speed, but also means RAM is the single hard capacity limit. Unlike a file based cache that simply keeps growing on disk, an undersized Redis server either leads to aggressive eviction that ruins the hit rate, or, without a configured maxmemory limit, to an out of memory state that can crash the entire Redis process.

Good memory sizing is therefore not a one time estimate made at project start, but an ongoing process that accounts for catalog growth, seasonal traffic peaks, and new features such as additional customer groups or language versions. A shop that gets by with 2 GB of RAM for Redis at launch may already need 8 GB after a year of organic growth, without anything fundamental changing in the architecture.

This article covers memory sizing separately for the three main roles cache, session and full page cache, because each role has a fundamentally different growth pattern: cache memory needs scale with catalog size, session memory needs scale with concurrent traffic, and FPC memory needs scale with the combination of page count and customer group variants.

2. Estimating cache memory needs

The general Magento cache covers configuration, layout XML, block HTML and EAV metadata. The largest variable portion is typically the block HTML cache, whose size grows directly with the number of products and categories. As a rule of thumb, budget 2 to 5 kilobytes of cache data per product, depending on theme complexity and the number of rendered blocks per product page.

For a catalog with 50,000 products, that comes out to roughly 100 to 250 megabytes of pure block HTML cache, plus configuration and layout cache, which usually sits in the low double digit megabyte range and barely scales with catalog size. Important for realistic memory sizing: this estimate applies per store view and language version, a shop with three languages multiplies cache memory needs accordingly, because every language version produces its own cached blocks.

# 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. Estimating session memory needs

Session memory needs follow a different pattern than cache: they do not scale with catalog size, but with the number of concurrently active visitors. A typical Magento session takes up between 2 and 10 kilobytes, depending on how much data is stored in the session, for example cart contents, recently viewed products, or intermediate form state in multi step checkouts.

For capacity planning, the relevant number is not total daily traffic, but the number of concurrently active sessions at peak load. A shop with 500 concurrent visitors at peak time and an average of 5 kilobytes per session needs roughly 2.5 megabytes of pure session storage, a comparatively small share of overall memory sizing. During traffic peaks from campaigns or sale events, however, the number of concurrent sessions can easily multiply tenfold, which should be explicitly accounted for in sizing rather than basing it only on normal operation.

4. Estimating FPC memory needs

The full page cache has the most complex memory footprint of the three roles, because it scales not only with page count but also with the number of variants per page. Every combination of page, customer group, currency and store view creates its own cache entry. A shop with 3 customer groups, 2 currencies and 2 store views multiplies the effective number of cache entries by a factor of 12 compared to a shop without those variants.

A fully rendered product page as HTML typically lands between 30 and 150 kilobytes, depending on theme complexity and embedded blocks such as cross selling widgets. For memory sizing purposes, multiply the number of cacheable pages (products plus categories plus CMS pages) by average HTML size and the variant factor. With 50,000 products, 500 categories, an average of 60 kilobytes per page and a variant factor of 4, that comes out to roughly 12 gigabytes of potential FPC memory needs, assuming every variant is actually visited and cached.

<?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. Configuring maxmemory and understanding eviction

In practice it is rarely sensible to size Redis for the theoretical maximum need, where every possible FPC variant is cached simultaneously. Realistic memory sizing accounts for the fact that only a fraction of all theoretically possible pages actually gets visited regularly, the so called Pareto principle: usually 20 percent of products generate 80 percent of traffic, and therefore also 80 percent of the entries actually cached.

The maxmemory directive in redis.conf sets a hard upper limit above which the configured maxmemory-policy kicks in. For the FPC, allkeys-lru makes sense, because rarely visited pages automatically get evicted from cache while frequently visited pages stay warm. Without a maxmemory limit, Redis keeps growing indefinitely until server RAM is exhausted, leading to a hard crash instead of controlled eviction.

# 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. Monitoring growth: INFO memory and --bigkeys

A one time memory sizing estimate at project start is not enough, because catalog size, traffic and usage patterns change continuously. redis-cli INFO memory provides the key metrics: used_memory_human shows current usage, used_memory_peak_human shows the historical peak, and mem_fragmentation_ratio shows how efficiently Redis actually uses the memory it has been allocated.

Systematic monitoring captures these values regularly, for example daily, and visualizes the trend over weeks and months. A linearly growing used_memory_human value over several months is a clear signal that the next capacity planning round is due, well before the maxmemory limit is actually reached. redis-cli --bigkeys complements this picture by finding unusually large individual entries, which can point to missing compression or inefficient caching of individual pages.

# 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. Capacity planning: formula and a practical example

A practical formula for initial memory sizing combines the three roles additively, with a safety buffer for fragmentation and unplanned growth: total memory equals cache need plus session need plus realistic FPC need (not the theoretical maximum), multiplied by a factor of 1.5 to 2 as a buffer. The buffer accounts for both Redis internal memory fragmentation and unforeseen traffic peaks.

Practical example: a mid sized shop with 20,000 products, 200 concurrent sessions at peak load, and a realistic FPC share of 15 percent of theoretically possible pages, comes out to roughly 60 megabytes of cache, 1 megabyte of session, and 1.8 gigabytes of realistic FPC need. With a buffer factor of 1.75, that results in about 3.3 gigabytes of recommended maxmemory limit, rounded up to 4 gigabytes for the next sensible instance size step.

8. Warning signs of undersized memory

The clearest warning sign of insufficient memory sizing is a dropping hit rate despite stable or growing traffic, visible in the ratio of keyspace_hits to keyspace_misses in redis-cli INFO stats. If this ratio drops noticeably even though nothing has changed in user behavior, it points to aggressive eviction from a maxmemory limit that is too tight.

A second warning sign is a high value for evicted_keys in INFO stats, which directly counts how many keys were removed due to memory pressure. A continuously growing value while traffic stays constant shows that current memory allocation no longer matches actual demand, and a capacity expansion is due before users actually notice the slowdown.

# 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 scenarios by shop size compared

The table below offers rough guideline values for typical shop sizes as a starting point for your own, more detailed calculations.

These guideline values serve as rough orientation and do not replace an individual calculation based on the formula described in this article. Factors such as the number of customer groups, language versions, and the actually used FPC share can shift real needs within a category by a factor of 2 to 3, which is why continuous monitoring matters more than a one time, static estimate.

10. Summary

Sound memory sizing for Redis in Magento requires looking at cache, session and full page cache separately, because each role grows according to different drivers: cache with catalog size, session with concurrent traffic, FPC with the combination of page count and customer group variants. An additive formula with a realistic, not theoretical, FPC share and a safety buffer of 1.5 to 2 provides a solid starting value for the maxmemory configuration.

Continuous monitoring through INFO memory, evicted_keys and the hit rate is essential, because catalog and traffic keep changing. Anyone treating memory sizing as a one time task at project start instead of an ongoing process risks a creeping performance degradation that is often noticed only once customers are already leaving.

11. FAQ: Memory Sizing for Redis in Magento Shops