Magento Redis: Configure Caching for Peak Store Performance

What is Redis in Magento?

Redis (Remote Dictionary Server) = an open-source, in-memory data store that handles caching and session storage for Magento. It replaces the default file-based system with sub-millisecond data access.

Perfect for: High-traffic Magento stores, multi-server clusters, stores with large catalogs and frequent cache invalidation

Not ideal for: Small development environments with minimal traffic, single-page sites with no dynamic content

Redis stores data structures in server RAM. Unlike disk-based databases, Redis delivers read and write operations in microseconds. Magento uses Redis for three core functions:

1. Default cache stores configuration data, layout XML, and block output
2. Full page cache stores complete HTML pages for instant delivery
3. Session storage manages user login states, cart contents, and checkout progress

The default file-based caching in Magento creates performance bottlenecks under load. The core_cache_tag database table can grow to millions of records within hours on busy stores. Redis eliminates this bottleneck by keeping all cache data in memory with automatic key expiration.

How Redis Works with Magento

Magento communicates with Redis through the Cm_Cache_Backend_Redis adapter. When a visitor requests a page, Magento checks Redis first. On a cache hit, Redis serves the stored data in microseconds. On a miss, Magento generates the data, stores it in Redis, and serves it to the visitor.

Session Storage

Redis manages user session data including login states, shopping carts, and checkout progress. File-based sessions create lock contention on high-traffic stores because PHP locks session files during each request. Redis handles concurrent session access without file locking.

Session data in Redis persists across server restarts when persistence is enabled. This prevents customers from losing their carts during deployments or server maintenance.

Page Caching

Redis caches complete HTML pages and content blocks. When configured for full page caching, Redis stores the rendered output of each page. Subsequent visitors receive the cached HTML without Magento processing the request through its full application stack.

This reduces server load from hundreds of PHP processes per second to a handful. The remaining PHP processes handle cache misses and dynamic content like customer-specific pricing.

Redis vs Valkey: What Changed

Redis changed its license from BSD to RSALv2/SSPL starting with version 7.4 in March 2024. Redis 7.2 remains the last BSD-licensed version. The new license restricts how cloud providers offer newer Redis versions as a managed service.

The Linux Foundation forked Redis 7.2.4 into Valkey, an open-source alternative with identical functionality. Valkey maintains full backward compatibility with Redis.

Magento 2.4.8 introduces official support for Valkey 8.x alongside Redis 7.2. Starting with 2.4.9-alpha2, Adobe replaces Redis with Valkey in CLI tooling. The env.php configuration remains identical, making the switch a drop-in replacement.

What this means for Magento stores:

No code changes are required to switch from Redis to Valkey. Check the Magento system requirements to verify compatibility with your version.

How to Configure Redis for Magento 2

The CLI method validates settings before writing them to env.php. Use this over manual file editing. For a complete walkthrough, see our Redis configuration tutorial.

Default Cache

bin/magento setup:config:set \
  --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 \
  --cache-backend-redis-port=6379 \
  --cache-backend-redis-db=0

Full Page Cache

bin/magento setup:config:set \
  --page-cache=redis \
  --page-cache-redis-server=127.0.0.1 \
  --page-cache-redis-port=6379 \
  --page-cache-redis-db=1

Session Storage

bin/magento setup:config:set \
  --session-save=redis \
  --session-save-redis-host=127.0.0.1 \
  --session-save-redis-port=6379 \
  --session-save-redis-log-level=3 \
  --session-save-redis-db=2

Resulting env.php Configuration

After running the CLI commands, your app/etc/env.php contains:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'database' => '0',
                'port' => '6379',
                'compress_data' => '1'
            ]
        ],
        'page_cache' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'database' => '1',
                'port' => '6379',
                'compress_data' => '1'
            ]
        ]
    ]
],
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2',
        'log_level' => '3'
    ]
]

Database Number Assignments

Adobe recommends these database assignments to prevent data conflicts:

Mixing cache types in one database causes data loss. Running bin/magento cache:flush on a shared database wipes session data along with cached pages.

L2 Cache: Local and Remote Combined

Magento's L2 cache adds a local file layer in front of Redis. This reduces network round-trips for repeated cache reads on the same server. For stores with advanced caching strategies, L2 cache provides the fastest possible read times.

Configure L2 cache in env.php:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
            'backend_options' => [
                'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
                'remote_backend_options' => [
                    'server' => '127.0.0.1',
                    'database' => '0',
                    'port' => '6379'
                ],
                'local_backend' => 'Cm_Cache_Backend_File',
                'local_backend_options' => [
                    'cache_dir' => '/dev/shm/'
                ]
            ]
        ]
    ]
]

The local cache uses /dev/shm/ (shared memory filesystem) for near-instant reads. Redis handles cross-server synchronization and cache invalidation.

When L2 cache helps most:

• Multi-server clusters where Redis runs on a separate node
• Stores with high cache hit rates on repeated requests
• Environments where network latency to Redis exceeds 1ms

Production Best Practices

Memory Management

Set maxmemory to cap Redis memory usage. Without a limit, Redis grows until the server runs out of RAM.

maxmemory 2gb
maxmemory-policy allkeys-lru

The allkeys-lru policy evicts the least accessed keys first. For stores with volatile (expiring) keys, use volatile-lru instead.

Compression

Enable compression when Redis memory exceeds 6GB:

'compress_data' => '4',
'compress_tags' => '4',
'compression_lib' => 'gzip'

Gzip compression reduces Redis memory usage by about 69%, depending on data composition. The tradeoff is higher CPU usage during compress and decompress operations. Enable this when you have spare CPU capacity.

Connection Resilience

Prevent intermittent failures during traffic spikes:

'read_timeout' => '10',
'connect_retries' => '5'

These settings give Redis time to recover from brief saturation without dropping requests.

Stale Cache

Enable stale cache to serve outdated content while Redis generates fresh data:

'use_stale_cache' => true

This reduces lock wait times and prevents cache stampedes where multiple requests try to rebuild the same cache entry at once. Combined with proper speed optimization, stale cache keeps response times consistent during high-traffic periods.

Monitoring

Track Redis health with built-in tools:

redis-cli info memory     # Memory usage and fragmentation
redis-cli info stats      # Hit rate, evictions, connections
redis-cli monitor         # Real-time command stream (use brief)

Watch these metrics:

Why Managed Hosting Simplifies Redis

Redis configuration requires server access, memory tuning, and ongoing monitoring. A single misconfiguration can crash your store during peak traffic.

Managed Magento hosting removes this burden. The hosting provider pre-configures Redis with optimal database assignments, compression settings, and memory limits for your traffic level.

Benefits of managed Redis hosting:

• Pre-configured Redis instances with separate databases for cache, FPC, and sessions
• Automated memory monitoring and alerting before evictions occur
• Redis and Valkey upgrades handled without store downtime
• L2 cache optimized for your cluster hosting setup

For stores running on auto-scaling infrastructure, managed hosting ensures Redis scales alongside your application servers without manual intervention.

FAQ

What is the difference between Redis and Valkey for Magento?

Valkey is a community fork of Redis 7.2.4 created after Redis changed its license. Both work with Magento 2.4.8 using identical configuration. The CLI commands and performance are the same. Adobe recommends Valkey for new installations and defaults to it in Commerce Cloud.

How much RAM does Redis need for a Magento store?

A typical production Magento store needs 1 to 2GB of Redis memory for default cache, 1 to 2GB for full page cache, and 512MB to 1GB for sessions. High-traffic stores with large catalogs may need 4 to 8GB total. Actual requirements depend on catalog size and store view count. Monitor usage with redis-cli info memory.

Can I use Redis for both caching and session storage?

Yes. Use separate Redis databases: database 0 for default cache, database 1 for full page cache, and database 2 for session storage. Never share a database between cache types. A cache flush would delete session data and log out all active customers.

How do I verify Redis is working in Magento?

Run redis-cli ping to confirm the server responds with "PONG". Then run redis-cli info keyspace to see if Magento stores data across your configured databases. In the Magento admin, check System > Cache Management to verify cache status shows as enabled.

What happens if Redis goes down?

Magento falls back to file-based caching and database session storage. The store keeps running with degraded performance. Page load times increase because every request hits the database. Restarting Redis restores normal performance without data loss if persistence is enabled.

Should I migrate from Redis to Valkey now?

If you run Magento 2.4.8 or later, Valkey 8 is a drop-in replacement with no configuration changes. Adobe Commerce Cloud already defaults to Valkey. For on-premises stores, both Redis 7.2 and Valkey 8 work. Plan your migration before 2.4.9 where Adobe replaces Redis in CLI tooling.

How does Redis compression affect performance?

Gzip compression with compress_data: 4 reduces memory usage by about 69%, depending on your store's data composition. The CPU overhead is minimal on modern servers. Enable compression when Redis memory exceeds 6GB or when running on memory-constrained instances.

What is the L2 cache in Magento?

L2 cache adds a local file layer using /dev/shm/ shared memory in front of Redis. Magento checks the local cache first, falling back to Redis on a miss. This reduces network round-trips in multi-server environments.

How do I flush Redis cache without affecting sessions?

Flush individual databases with redis-cli -n 0 FLUSHDB for default cache or redis-cli -n 1 FLUSHDB for page cache. Never use FLUSHALL as it clears all databases including session data in database 2.

Does Redis improve Magento Core Web Vitals?

Redis reduces page load times, which affects Largest Contentful Paint (LCP) and Time to First Byte (TTFB). Faster page delivery reduces bounce rates and improves user engagement. For international traffic, combine Redis with a CDN for the fastest response times.