Redis in Magento 2 is not a single thing – it serves three distinct roles that should ideally run as separate instances with different configurations. Object cache, Full Page Cache, and session storage have very different access patterns and eviction requirements. I show how to configure each, why separate instances matter, and how to monitor what is happening.
Three roles, three configurations
| Role | Typical size | Eviction policy | Persistence |
|---|---|---|---|
| Object cache | 512MB – 2GB | allkeys-lru | No (fast rebuild) |
| Full Page Cache | 1GB – 8GB | allkeys-lru | No |
| Sessions | 256MB – 1GB | volatile-lru | Yes (AOF) |
env.php configuration – three separate Redis instances
<?php
// app/etc/env.php
return [
'cache' => [
'frontend' => [
'default' => [
'id_prefix' => 'abc_',
'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
'backend_options' => [
'server' => 'redis-cache', // dedicated instance
'port' => '6379',
'database' => '0',
'password' => '',
'compress_data' => '1',
'compress_threshold'=> '2048',
'compression_lib' => 'gzip',
],
],
'page_cache' => [
'id_prefix' => 'abc_',
'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
'backend_options' => [
'server' => 'redis-fpc', // separate FPC instance
'port' => '6379',
'database' => '0',
'compress_data' => '1',
],
],
],
],
'session' => [
'save' => 'redis',
'redis' => [
'host' => 'redis-session', // separate session instance
'port' => '6379',
'database' => '0',
'password' => '',
'timeout' => '2.5',
'persistent_identifier' => '',
'compression_threshold' => '2048',
'compression_library' => 'gzip',
'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',
],
],
];
Why separate instances?
Running all three on one Redis instance creates problems:
- Sessions must never be evicted (user gets logged out) but cache can be
- FPC entries are large; object cache entries are small – different memory characteristics
- A spike in FPC writes can evict active sessions if they share memory
- Different maxmemory-policy settings cannot coexist on one instance
# redis-cache: allkeys-lru - evict any key when full redis-cli -h redis-cache CONFIG SET maxmemory-policy allkeys-lru redis-cli -h redis-cache CONFIG SET maxmemory 2gb # redis-fpc: allkeys-lru redis-cli -h redis-fpc CONFIG SET maxmemory-policy allkeys-lru redis-cli -h redis-fpc CONFIG SET maxmemory 4gb # redis-session: volatile-lru - only evict keys with TTL set (not sessions) redis-cli -h redis-session CONFIG SET maxmemory-policy volatile-lru redis-cli -h redis-session CONFIG SET maxmemory 512mb
Monitoring Redis from CLI
# Connection stats and memory redis-cli INFO server | grep redis_version redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human" redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses|evicted_keys" # Hit rate calculation # hit_rate = keyspace_hits / (keyspace_hits + keyspace_misses) # Good: > 90% Warning: 70-90% Problem: < 70% # Real-time commands monitor (use sparingly on production) redis-cli MONITOR | grep -v PING # Key count per database redis-cli INFO keyspace # Memory usage of a specific key redis-cli MEMORY USAGE "abc_mage-tags-EAV_ENTITY_TYPES_1" # Slowlog - find slow commands redis-cli SLOWLOG GET 10
Redis in DDEV - multi-instance setup
# .ddev/docker-compose.redis.yaml
version: '3.6'
services:
redis-cache:
image: redis:7-alpine
command: redis-server --maxmemory 512mb --maxmemory-policy allkeys-lru
labels:
com.ddev.site-name: ${DDEV_SITENAME}
redis-fpc:
image: redis:7-alpine
command: redis-server --maxmemory 1gb --maxmemory-policy allkeys-lru
labels:
com.ddev.site-name: ${DDEV_SITENAME}
redis-session:
image: redis:7-alpine
command: redis-server --maxmemory 256mb --maxmemory-policy volatile-lru --appendonly yes
labels:
com.ddev.site-name: ${DDEV_SITENAME}
Summary
Redis is the backbone of Magento 2 performance - but only when configured correctly. Separate instances with appropriate eviction policies prevent the worst failure mode: evicting user sessions because FPC filled the shared memory. Monitor hit rates weekly - a drop below 80% on the object cache means something is generating too many unique cache keys, which warrants investigation.
