Magento 2 Redis Configuration: The Complete Guide for 2026

Redis is table stakes for any production Magento store. But "just install Redis" is not enough — the default configuration leaves significant performance on the table. Here's how to configure it correctly.

Why separate Redis instances matter

Many guides tell you to point all Magento caches at a single Redis instance. Don't do this.

Magento uses Redis for three distinct workloads:

1. Default cache — config, layouts, translations (many small, short-lived keys)
2. Full Page Cache (FPC) — rendered HTML pages (large values, longer TTL)
3. Sessions — customer session data (medium values, must persist)

Mixing these in one instance creates problems:

• FPC's large HTML values evict small config cache entries under memory pressure
• A cache flush (cache:flush) wipes sessions if they share the same database
• You can't tune eviction policy per workload

The right setup: 3 separate Redis instances (or at minimum, separate databases on one instance with different maxmemory settings).

env.php configuration

<?php
return [
    'cache' => [
        'frontend' => [
            'default' => [
                'id_prefix' => 'mage_',
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => '127.0.0.1',
                    'database' => '0',
                    'port' => '6379',
                    'password' => '',
                    'compress_data' => '1',
                    'compression_lib' => 'lzf',
                ],
            ],
            'page_cache' => [
                'id_prefix' => 'mage_fpc_',
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => '127.0.0.1',
                    'database' => '1',  // separate DB
                    'port' => '6379',
                    'compress_data' => '1',
                    'compression_lib' => 'lzf',
                ],
            ],
        ],
    ],
    'session' => [
        'save' => 'redis',
        'redis' => [
            'host' => '127.0.0.1',
            'port' => '6379',
            'password' => '',
            'timeout' => '2.5',
            'persistent_identifier' => '',
            'database' => '2',  // separate DB
            'compression_threshold' => '2048',
            'compression_library' => 'lzf',
            'log_level' => '1',
            'max_concurrency' => '6',
            'break_after_frontend' => '5',
            'break_after_adminhtml' => '30',
            'first_lifetime' => '600',
            'bot_first_lifetime' => '60',
            'bot_lifetime' => '7200',
            'disable_locking' => '0',
            'min_lifetime' => '60',
            'max_lifetime' => '2592000',
        ],
    ],
];

Redis server configuration

Tune your Redis redis.conf per workload:

For default cache (DB 0) — aggressive eviction, it's rebuildable:

maxmemory 512mb
maxmemory-policy allkeys-lru

For full page cache (DB 1) — larger allocation, LRU eviction:

maxmemory 2gb
maxmemory-policy allkeys-lru

For sessions (DB 2) — no eviction, sessions must persist:

maxmemory 256mb
maxmemory-policy noeviction

The noeviction policy for sessions is critical. Without it, Redis can evict session keys under memory pressure — silently logging customers out.

Connection pooling with PHP-FPM

Each PHP-FPM worker opens its own connection to Redis. With 100 workers and 3 Redis connections each, you're looking at 300 simultaneous connections.

Mitigate this with persistent_identifier in your session config and connection pooling via Twemproxy or Redis Cluster if you're at scale.

Compression settings

Enabling compression reduces memory usage by 40–60% for typical Magento cache values:

Library	Speed	Ratio	Best for
lzf	Very fast	~2x	Default cache, sessions
lz4	Extremely fast	~2x	High-throughput FPC
zstd	Fast	~3-4x	Large HTML pages in FPC

Set compression_threshold to 2048 bytes — don't compress small values, the overhead isn't worth it.

Monitoring Redis health

Check these regularly:

# Overall stats
redis-cli info stats

# Memory usage
redis-cli info memory | grep used_memory_human

# Hit rate (aim for > 95%)
redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

# Top 10 slowest commands
redis-cli slowlog get 10

# Keys by database
redis-cli info keyspace

Hit rate formula: hits / (hits + misses) * 100

If your hit rate drops below 80%, you either have a memory pressure problem (increase maxmemory) or a cache invalidation problem (too aggressive flushing).

Cache warming after deploys

After a full cache flush (e.g. post-deploy), your store will be slow until Redis warms back up. Automate warming:

#!/bin/bash
# warm-cache.sh — crawl top pages after deploy
urls=(
  "https://your-store.com/"
  "https://your-store.com/catalog/category/view/id/5"
  "https://your-store.com/catalog/product/view/id/100"
)

for url in "${urls[@]}"; do
  curl -s -o /dev/null "$url"
  echo "Warmed: $url"
done

The BetterMagento Redis Turbo module automates cache warming, monitors hit rates in the admin panel, and provides tag-based invalidation so you never have to flush the entire cache again.

Quick reference: common mistakes

Mistake	Fix
Single Redis instance for all caches	Use separate databases or instances
No compression	Enable lzf compression
noeviction on cache (not sessions)	Use allkeys-lru for cache
Sessions sharing DB with cache	Separate DB, noeviction policy
No monitoring	Track hit rate, memory, slowlog
Full flush on every deploy	Use tag-based invalidation

---

Originally published on magevanta.com