Separate cache/shared node tables on multi-site setup

Events happening in the community are now at Drupal community events on www.drupal.org.
raintonr's picture

Hi,

Sorry if this is an RTFM, but a quick search finds this thread:

http://groups.drupal.org/node/4247

Here and elsewhere it is recommended that cache* tables be kept separate for multi-site deployments.

I've been running multiple sites, which share some content for some time. These sites are same codebase, same database with only 4 tables that aren't shared (see next paragraph). The content sharing rules are a bit complex so wrote my own access module which grants access based on the domain being used (the one the request is coming in on) and some other rules about content.

The only tables that are unique to each site (prefixed) are: cache, cache_block, cache_page, url_alias.

To be honest, I'm not convinced that even the cache tables should be in this list. I'm beginning to think url_alias is the only one required.

To make things even more interesting, am using memcache.module and give each site it's own prefix so memcache objects are all kept separate. Whether or not this is the correct thing to do, I don't know, but...

... anyhow - it has been working as is (with the 4 tables mentioned above and memcache separated) without page caching turned on. I should also mention that each site has it's own theme which allows individual block configuration for example. I override certain variables in the settings.php file for each site.

I recently enabled page caching for performance reasons though and am not happy with the result.

For example, user accesses site on domain1.com and deletes a node. I notice that in the node.module node_delete function there's a call to cache_clear_all. However, this only clears the cache on domain1.com. An anonymous user then accesses domain2.com which happens to share the content just deleted, but because the cache table on domain2.com is separate this content is still in the cache there and it is seen.

I guess what am asking here is... what are best practices for this kind of deployment? What will happen if one shares cache* tables? What will happen if one doesn't separate memcache data? Has anyone done this? Are there any hooks to do with caching that one should be utilising in the scenario above?

Thanks in advance :)

Comments

depends on your site

mikeytown2's picture

Having a different cache for each site depends on how you want your flush all caches to work. The cache_page table should compatible with multiple domains and not having this shared might be a good idea due to CSS/JS aggregation; pages in the cache could be referencing non-existing css/js files due to the way the flush cache works (it kills everything in the files/css & files/js dir).
http://api.drupal.org/api/function/drupal_clear_css_cache/6
http://api.drupal.org/api/function/drupal_clear_js_cache/6

I haven't played around with the other cache tables enough to advise you on them.

Shared Caching works

raintonr's picture

@mikeytown2: I think you're right. Having seen that I changed the config on a development environment to share all cache tables. Ie. the only separate table across multisites is now url_alias.

This seemed to work as desired. I was slightly worried about cached variables (settings), but as I specifically set any differences required to $conf in the specific site's settings.php think that may not matter.

FWIW, I am still a bit confused about how long cached pages are meant to hang around. For example, I visited the test site (the same domain) as both a logged in user and guest at the same time (using 2 different browsers). Deleted content when logged in, but didn't see that disappear from the guest browser immediately. It did disappear some time later, I'm guessing this delay is that which is configured in the minimum cache lifetime setting, but am really guessing there - I'm not sure how page or content caching is supposed to work here.

High performance

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: