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.