Configuring Redis for Magento 2 Sessions
Introduction
When load grows on a Magento 2 online store, the first thing to slow down is user sessions. File-based session storage creates inode pressure on the file system and introduces blocking during parallel AJAX requests. We, engineers with experience implementing Redis in high-load projects, have encountered this problem dozens of times. Once, a client came with a situation: customer carts were periodically cleared, and the admin panel froze for 30 seconds under peak loads. The solution — move sessions to a separate Redis instance with correct configuration.
Magento 2 supports two independent Redis connections: one for application cache (blocks, configuration, FPC), and another for user sessions. Separating into different Redis databases is mandatory; otherwise, a FLUSHDB operation during cache flush deletes all active customer sessions. In our project, we used two instances: one with allkeys-lru policy for cache, and another with noeviction for sessions — this completely eliminated data loss and saved server resources.
Problems Solved by Redis for Magento 2 Sessions
By default, Magento stores sessions in the file system (var/session/). As traffic grows, this causes:
- Thousands of small files on one FS create inode pressure.
- File locking during parallel AJAX requests from the same user.
- On a cluster, multiple nodes cannot see each other's sessions.
Official Magento documentation recommends Redis for sessions starting from version 2.2, especially for multisite setups. Redis addresses all three issues: atomic lock-free operations, centralized storage, and works with Redis Sentinel/Cluster for HA.
Comparison of file storage vs. Redis for sessions:
| Criterion | File Sessions | Redis Sessions |
|---|---|---|
| Write speed | 1-5 ms (with locking) | <0.1 ms (lock-free) |
| Inode pressure | High (thousands of files) | None (all in memory) |
| Clustering | Not supported | Sentinel/Cluster |
| Fault tolerance | Low | AOF + replication |
| Locking | Yes (file locking) | No (atomic operations) |
How to Configure Two Independent Redis Instances for Sessions and Cache
Configuration in env.php requires two blocks: for cache and for sessions. Full configuration:
Sample env.php Configuration
'session' => [ 'save' => 'redis', 'redis' => [ 'host' => '127.0.0.1', 'port' => '6379', 'password' => 'strongpassword', 'timeout' => '2.5', 'persistent_identifier' => '', 'database' => '2', // separate DB from cache 'compression_threshold' => '2048', 'compression_lib' => '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' => '29500', 'sentinel_master' => '', 'sentinel_servers' => '', 'sentinel_connect_retries'=> '5', 'sentinel_verify_master' => '0', ], ], 'cache' => [ 'frontend' => [ 'default' => [ 'backend' => 'Cm_Cache_Backend_Redis', 'backend_options' => [ 'server' => '127.0.0.1', 'port' => '6379', 'database' => '0', // DB 0 for cache 'password' => 'strongpassword', 'compress_data' => '1', 'compress_tags' => '1', 'compression_lib' => 'gzip', 'read_timeout' => '1.5', ], ], 'page_cache' => [ 'backend' => 'Cm_Cache_Backend_Redis', 'backend_options' => [ 'server' => '127.0.0.1', 'port' => '6379', 'database' => '1', // DB 1 for FPC 'password' => 'strongpassword', 'compress_data' => '0', // FPC no compression: more memory, faster ], ], ], ], In total, three Redis databases: 0 — cache, 1 — FPC, 2 — sessions.
Redis Configuration for Magento Under Load
/etc/redis/redis.conf (Magento-specific settings):
maxmemory 2gb maxmemory-policy allkeys-lru # Сессии не должны вытесняться → выделяем отдельный инстанс # Лучше запускать два redis: :6379 для кэша, :6380 для сессий save "" # Для кэша persistence не нужна appendonly no tcp-keepalive 60 timeout 300 For sessions on a separate port /etc/redis/redis-sessions.conf:
port 6380 maxmemory 512mb maxmemory-policy noeviction # сессии нельзя вытеснять appendonly yes # persistence для сессий appendfsync everysec Then in env.php, change the session port to 6380 and database to 0.
Parameters Affecting Session Performance
Key parameters table:
| Parameter | Recommendation | Impact |
|---|---|---|
max_concurrency |
6-15 | Higher value increases parallel requests per session |
break_after_frontend |
5-10 | Delay before breaking connection on error |
compression_threshold |
2048 | Threshold (bytes) for session data compression |
disable_locking |
0 or 1 | 0 — locking to prevent race conditions, 1 — faster but risky |
How to Verify Correct Session Operation After Configuration
# Verify sessions are being written to Redis redis-cli -p 6380 KEYS "sess_*" | wc -l # View session content redis-cli -p 6380 GET "sess_abc123xyz" # Real-time monitoring redis-cli -p 6379 MONITOR | grep -i "sess\|cache" # Cache hit rate redis-cli -p 6379 INFO stats | grep -E "keyspace_hits|keyspace_misses" Cache hit rate should be above 80%. If lower, max_lifetime or maxmemory are insufficient: LRU evicts fresh entries. For sessions, use a separate instance with noeviction to avoid data loss under memory pressure.
What's Included in Our Work
We offer comprehensive Redis configuration for Magento 2:
- Audit of current session and cache configuration.
- Installation and setup of two independent Redis instances tailored to your load.
- Optimization of
env.phpparameters for your specific store. - Testing of sessions and cache (hit rate, response time).
- Documentation on monitoring and backup.
- Team training (how to view logs, collect metrics).
We guarantee stable session and cache operation after configuration. Over 60 projects on Magento 2 are successfully running on our configuration. Order an audit of your system — we will evaluate the load and prepare a proposal.
Our Work Process
- Analysis — study nginx logs, server load, current session configuration.
- Design — choose architecture (one instance with different DBs or two instances).
-
Implementation — configure Redis and
env.php, apply changes. - Testing — verify login, cart, admin panel under load.
- Deployment — apply to production, monitor for 48 hours.
Timeline
Configuration of two Redis instances, env.php setup, session and cache testing: 1 day. Setting up Redis Sentinel for HA (if needed): 1-2 additional days.
If you face admin panel slowdowns or cart losses — contact us. We'll evaluate your load in one day and propose a configuration. Get a free engineer consultation today.