Sessions Lock and Full Page Cache: Investigation Using New Relic
This article describes the process of investigating and resolving Magento performance issues during mass email campaigns related to session locking. It examines the use of New Relic for diagnostics and analysis of optimization results.
User Story
Quite often, especially during major email campaigns, the client complains about server performance issues. They constantly contact the hosting provider to perform scaling during these periods and check autoscaling functionality. However, this provides little help.
Investigation Process
During the problem investigation in New Relic, sharp spikes were noticed during email campaigns. These spikes indicated serious performance issues that weren't resolved by simple resource scaling.
Further analysis showed that the spikes led to Redis, indicating that the locking mechanism was being triggered. This became a key clue for understanding the root of the problem.
Session Lock Analysis
After investigating the problem, it became clear that the issue was with session locking. Magento out-of-the-box locks sessions in such a way that you cannot open a second tab with the same user.
Problem Manifestations
Session locking is especially visible in the admin panel when something resource-intensive occurs:
- Large mass actions in one tab
- Complete blocking of the second tab during operation execution
- Request queue accumulation during email campaigns
- Significant increase in response time for all users
Investigation Results
| Metric | Before Optimization | After Optimization |
|---|---|---|
| Average Response Time | 8.5 sec | 1.8 sec |
| Peak Values | 15.2 sec | 2.3 sec |
| Redis Connection Locks | High | Minimal |
Solution
Non-blocking Sessions Configuration
- Changed session locking configuration
Risk Analysis
- Assessed potential shopping cart conflicts
- Monitored multi-tab behavior
The client was offered non-blocking sessions configuration. Yes, there is a small risk in case of simultaneous actions affecting, for example, the shopping cart from the same user when working in two tabs. However, the risk is extremely small, while Magento Cloud sets this value by default everywhere.
Configuration Settings
To implement non-blocking sessions, you need to modify the env.php configuration file. The key setting is the disable_locking parameter in the session configuration:
env.php Configuration
'session' => [
'save' => 'redis',
'redis' => [
...
'disable_locking' => '1',
...
]
],Important: Set 'disable_locking' => '1' to enable non-blocking sessions.
For detailed configuration options, refer to the official Magento documentation.
Results
Eliminated Load Spikes
Spikes related to session problems have completely disappeared. The system shows stable operation even during mass email campaigns.
Stable Performance
During email campaigns, stable performance is observed. Page load time does not exceed 2 seconds during peak moments.
Conclusion
The investigation showed that Magento performance issues during email campaigns are often related not to server resource shortages, but to architectural features of session management. Using non-blocking sessions allowed for dramatically improved system performance with minimal risks to functionality.