Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When upgrading from 6.x-1.5 to 6.x-1.9, we're seeing some performance issues (using the memcached extension). We've identified that much of the performance hit is due to cache not getting set for the theme registry. This is the only cache set that returns false when switching between 6.x-1.5 and 6.x-1.9. The function in question is dmemcache_set and here are the lines that return false:
if ($mc instanceof Memcached) {
$success = $mc->set($full_key, $value, $exp);
}
Any insight is appreciated. The cache id is 'theme_registry:theme_name'.
Comments
Comment #1
djbobbydrake CreditAttribution: djbobbydrake commentedFigured out the solution. The 6.x-1.9 version sets memcached compression to FALSE by default. Values greater than 1mb can't be stored in memcache, and it turned out that our theme registry value was greater than 1mb. After enabling compression in our settings.php file, we were able to add the theme registry value to the cache:
Performance has been restored to what it was with 6.x-1.5.
Comment #2
djbobbydrake CreditAttribution: djbobbydrake commentedI would propose that we default compression to TRUE, as that default behavior seems ideal, especially if defaulting compression to FALSE will result in poor performance. Also, overriding this setting in settings.php file will result in a php error if use of memcache.so extension is forced on the server side.
Comment #3
catchWe now default to the PECL memcache extension instead of memcached since the latter has several unresolved bugs.
Defaulting to compression true for memcached sounds like a decent fix to me.
Also see #1011614: Theme registry can grow too large for MySQL max_allowed_packet and memcache default slab size.
Comment #4
Jeremy CreditAttribution: Jeremy commentedPlease see the README.txt that comes with the module:
Note in particular the first bullet point above, "turn off compression, as this takes more CPU cycles than its worth for most users". This was decided after doing considerable load testing, so to change this default we should first do some load testing reviewing overall performance, network traffic, and server load to understand if the benefit is sufficient to make it a default. It's simple to override the default, so I still favor the more conservative default we currently have.
Comment #5
catchIn that case I think we should continue focusing on the > 1mb cache items in core and just work on the other patch that logs when this happens. Going to mark this duplicate. .
Comment #6
TribalMan CreditAttribution: TribalMan commentedI added the solution as described however I get a Fatal error: Class 'Memcache' not found. I double checked my php.ini file and found "extension=memcache.so" to be present. My memcached installation still works fine for a drupal site using the previous version of the module. Any idea where I might have gone wrong here?