Magento 2 - Best Session Storage
Introduction
When developing Magento 2 e-commerce stores, choosing the right session storage mechanism is critically important. It affects not only site performance but also user data integrity. In this article, we'll compare three main types of storage.
How Sessions Work in Magento 2
Before testing, it's important to understand the key principles of session operation:
- All operations happen in PHP memory —
setandgetmethods don't write data immediately to storage - Data loading occurs when calling
session_start()at the beginning of application execution - Data saving happens only when the script terminates via
writeClose()
Session Types in Magento 2
Magento 2 has several typical session storage configurations:
- DB — storage in MySQL database
- Files — storage in filesystem
- Redis disable_locking => 1 — without locking (fast but risky)
- Redis disable_locking => 0 — with full locking (safe but slow)
- Redis disable_locking => 0, break_after_frontend => N — with limited locking (compromise)
Testing Methodology
For objective evaluation, we created a special test script that simulates a real situation — two concurrent requests trying to write different data to the same session.
Test Scenario:
- Session cleanup — start with clean state
- Parallel execution of two requests in different browser tabs:
- Request A: runs for 30 seconds and writes
value=X - Request B: completes quickly and writes
value=Y
- Request A: runs for 30 seconds and writes
- Result verification — which data remained in the session?
This test reveals two critical characteristics:
- Data integrity — were both values preserved or did one overwrite the other?
- Performance — how long did the second request wait for the first to complete?
Test Results
All results are consolidated in a comparison table:
| Storage | Configuration | Locking | Performance | Test Result | Data Lost? | Recommendation |
|---|---|---|---|---|---|---|
| DB | Default | ❌ No | ⚡⚡⚡ Instant | X Y lost |
✅ YES | ⛔ Not recommended |
| Files | Default | ✅ Yes | ⚠️ Waits 15 sec | XY Nothing lost |
❌ NO | ⚠️ Dev only |
| Redis | disable_locking => 1 |
❌ No | ⚡⚡⚡ Instant | X Y lost |
✅ YES | ✅ RECOMMENDED |
| Redis | disable_locking => 0 |
✅ Yes | ⚠️ Waits 15 sec | XY Nothing lost |
❌ NO | ⚠️ For critical data only |
| Redis | disable_locking => 0break_after_frontend => 5 |
⚠️ Partial (5 sec) | ⚡⚡ Waits 5 sec | Y X lost |
✅ YES | ✅ Good alternative |
| Redis | disable_locking => 0break_after_frontend => 15 |
⚠️ Partial (15 sec) | ⚡⚡ Waits 15 sec | X Y lost |
✅ YES | ✅ Optimal |
| Redis | disable_locking => 0break_after_frontend => 60 |
⚠️ Partial (60 sec) | ⚠️ Waits up to 60 sec | XY Nothing lost |
❌ NO | ⚠️ Too slow |
Final Observations
While it's clear that disable_locking => 1 can lead to data overwrites during parallel requests, in practice this happens infrequently. It typically occurs with parallel AJAX requests or when users work very intensively across multiple tabs on your site.
disable_locking => 1 is the default value. This is because with disable_locking => 0 you get perfect session integrity, but locks occur very frequently, especially with poorly written code.
For example, one resource-intensive operation can completely block site access. You may see this during real-time admin operations like exports. If an export takes 1 minute, you've probably noticed you can't navigate the admin panel. This is session lock. Therefore, a compromise is needed.
Our Recommendations
1. Use disable_locking => 1
Eliminate parallel AJAX requests during checkout as much as possible, especially during place order. This will prevent most data loss issues.
2. Alternative: disable_locking => 0, break_after_frontend => 5
This configuration provides balance between performance and data safety. A 5-second lock is sufficient for most quick operations (add to cart, update quantity), but doesn't completely block the site during long operations.
Why this works:
- Most AJAX requests in Magento 2 complete within 1-3 seconds
- If a request completes faster than 5 seconds — data is saved correctly
- Long operations (over 5 seconds) don't block users in other tabs
- Reduces risk of site "freezing" with code issues
break_after_frontend => 5, ensure critical operations (place order, payment) complete faster than this time. Otherwise, use a higher value (15-30 seconds).
3. disable_locking => 0 — only in extreme cases
We recommend using full locking only if you have:
- Frequent data loss in orders
- Strange cart or checkout behavior
- Critical financial operations requiring 100% guarantee
Even then, we advise detailed debugging first and returning to disable_locking => 1 after fixing the root cause.
Contact us for assistance — we have extensive experience in this area. We'll help identify and fix the problem without needing to slow down your entire site.
4. Files/DB sessions — not recommended
We don't recommend using file-based or database sessions — use Redis instead. Only if you don't have Redis available, choose one of these options.
Summary Recommendations Table
| Use Case | Recommended Configuration |
|---|---|
| High-traffic e-commerce store | disable_locking => 1 + AJAX optimization |
| Medium-traffic store | disable_locking => 0, break_after_frontend => 15 |
| Store with critical data (payments, B2B) | disable_locking => 0, break_after_frontend => 30-60 |
| Development and testing | Files or disable_locking => 0 |
| Content site without cart | disable_locking => 1 |
Conclusion
Choosing the right session storage mechanism is critically important for stable Magento 2 operation. There's no universal solution — the choice depends on load, data type, and your project's business requirements.
Our experience shows that Redis with disable_locking => 1 or break_after_frontend => 15 provides optimal balance between performance and reliability for most e-commerce stores.