When the configuration cache in Magento is cleared, it can lead to multiple requests starting the cache creation process. This increases the CPU resources and may lead to your site being inaccessible. CTI Digital have created a fix for this using a cache lock in Redis.

1. PAUL PARTINGTON
Magento Developer at CTI Digital
@paul_partington

2. What are We Talking
About?
• Caching approaches
• Look at an issue with the configuration cache that
we found
• How we fixed it

3. Web Server 1
Web Server 2
Magento
Block
Layout
Configuration
Collections
EAV
API
Full Page Cache
Database
APC Cache
Query Cache
Varnish

4. Cache Storage
• File
• Database
• Redis or Memcached

5. The Configuration Cache
• Combines the XML files in the system
• Adds in the system configuration
• Every time you add a new module the size
increases

6. • Every time you add a new website you increase the
size of the configuration XML
• Adds around 125KB on Magento EE 1.14.2.0
Multisite

7. I think I see where you’re
going with this
• Multiple Websites (9)
• High Traffic
• Caches are going to get cleared
• The configuration cache was cleared and took the
site down

8. Why’s this happening?
• While the configuration cache is being created,
every request causes the cache generation process
to start
• CPU load increased as the request uses more
memory and takes longer to finish

9. app/code/core/Mage/Model/App.php
protected function _initModules()
{
if (!$this->_config->loadModulesCache() {
$this->_config->loadModules();
...
}
}

10. 0
0.25
0.5
0.75
1
1.25
-20 -10 0 10 20 30
CPULoad
Time
CPU Load

11. Cache Policy
• Caches should only be cleared at non-peak times
• Clients should be aware of the effects that clearing
a cache can have

12. What did we do?
• Created a module
• https://github.com/ctidigital/Configuration-Cache-
Lock
• Similar fix -
https://github.com/madepeople/Made_Cache

13. How does the module
work?
• Creates a cache lock in a Redis database
• Keep the cache creation to a single request

14. <global>
...
<cache_lock>
<enable>1</enable> <!-- If cache locking is enabled or not -->
<server>127.0.0.1</server> <!-- The Redis database IP -->
<port>6379</port> <!-- The Redis port -->
<database>0</database> <!-- The Redis Database to use -->
<password></password> <!-- The password of the Redis server -->
<timeout>2.5</timeout> <!-- The Redis timeout -->
<key>cache_lock</key> <!-- The name of lock in the Redis Database -->
<max_attempts>10</max_attempts> <!-- The maximum amount of times to retry the
connection. Defaults to 10. -->
<retry_time>10000000</retry_time> <!-- The amount of microseconds to wait between checking
the cache has generated. Defaults to
10000000 -->
</cache_lock>
...
Edit your local.xml

15. • Creates a local override of Mage_Core_Model_App
(sorry!)
• New method called _initModulesWithLocking()

16. protected function _initModulesWithLocking ()
{
if ($this->_config->loadModulesCache()) {
return $this;
}
...
// If the cache is currently being regenerated
if ($ctiCache->getIsCacheLocked()) {
$cacheLock = true;
}
// If the cache needs to be created
if ($cacheLock === false) {
// Create a new cache lock
$ctiCache->acquireCacheLock();
$this->_config->loadModules();
...
// Release the cache lock
$ctiCache->releaseCacheLock();
return $this;
}
...
while ($cacheLock === true && $attempts < $maxAttempts) {
$attempts++;
usleep($ctiCache->getRetryTime());
if ($this->_config->loadModulesCache()) {
return $this;
}
}

17. 0
0.25
0.5
0.75
1
1.25
-20 -10 0 10 20 30
CPULoad
Time
Without the Cache Lock With the Cache Lock

18. An Unexpected Extra
• Prevents module updates from running more than
once
• Poorly written update scripts may display an error if
ran more than once

19. Further Reading
• http://alanstorm.com/magento_config_a_critique_an
d_caching

20. Thank You
• @paul_partington
• @CTIDigitalUK