Hi all,
I have been having some performance problems on a Drupal multi-site installation. Or rather, some users have been complaining of poor performance so am investigating...
The site(s) in question (totals in the same DB) have over 10,000 users and serve up around 180K hits/72K pages a day. The site is a variety of images, forum, blogs, calendar, etc. but majority of traffic is in the forum. There are 26K nodes, 85K comments in the system.
I'm trying various things, but this post relates to memcache config. This is with memcache 1.9. I decided to try several bins and then tune as needed, so created this config:
<?php
$conf['memcache_servers'] = array(
'localhost:11211' => 'default',
'localhost:11212' => 'block',
'localhost:11213' => 'content',
'localhost:11214' => 'filter',
'localhost:11215' => 'form',
'localhost:11216' => 'menu',
'localhost:11217' => 'page',
'localhost:11218' => 'update',
'localhost:11219' => 'views',
'localhost:11220' => 'session',
'localhost:11221' => 'users',
);
$conf['memcache_bins'] = array(
'cache' => 'default',
'cache_block' => 'block',
'cache_content'=> 'content',
'cache_filter' => 'filter',
'cache_form' => 'form',
'cache_menu' => 'menu',
'cache_page' => 'page',
'cache_update' => 'update',
'cache_views' => 'views',
'cache_session'=> 'session',
'cache_users' => 'users',
);
?>This is interesting as the following bins are completely empty after several hours of running:
localhost:11212 (block)
localhost:11214 (filter)
localhost:11218 (update)
localhost:11220 (session)
localhost:11221 (users)
I also notice that the filter bin has 1 hit and many thousand misses and no sets. That bin at least looks very ill!
Does anyone else find this odd? Any ideas what is wrong with filter caching? It's not like we are using PHP or anything, just standard HTML.
Oh, as a side issue I notice that 'page' has -174% free. I assume multiple memcached processes 'borrow' RAM from others when they overflow and this isn't anything to be alarmed by (aside from needing to boost that particular bin of course).
Comments appreciated.
Many thanks,
Robin
Comments
block is typically empty, like some others
On many sites, and probably yours, node access control is turned on, which disabled block caching, meaning the block cache is never used and you can just as well leave it assigned to the DB and reassign its ram to other bins.
update is only filled by by update checks, which are probably turned off on a production sites to avoid the performance hit when it triggers, so it needn't be in memcache either.
page will normally be empty if you use pressflow with external caching mode.
No Pressflow
Thanks for the info.
Sorry, forgot to mention we're not using Pressflow. This is core 6.16 (little behind on the updates).
Any idea on the filter though? This looks like a bug as is sets just aren't being saved :(
cache_filter
Ah... I had a look at the filter formats table and noticed that all formats had cache = 0!
I've updated this to cache the HTML formats that are most used and bingo.
I made the update in the database directly. Does anyone know how this is meant to be updated through the admin interface and why cache is disabled by default?
Filter caching
Filter caching is defined in hook_filter_info() (D7): http://api.drupal.org/api/drupal/modules--filter--filter.api.php/functio... or hook_filter('info') (D6): http://api.drupal.org/api/drupal/developer--hooks--core.php/function/hoo...
Some filters should usually NOT be cached, like the PHP filter, since it is precisely used to build dynamic content (hence non cacheable) content.