Multiple Drupal Sites on same server with Memcache

Multiple Drupal Sites on same server with Memcache

Multiple Drupal Sites on same server with MemcacheRecently, the non-profit I work for made the decision to move to new VPS services. As part of the move we also were able to implement APC and Memcache as part of our performance strategy now that we are in a hosting environment we can actually control.

On our production boxes we installed our production site as well as a copy of production for staging purposes. For us, this is used for final QA testing prior to production deployment. This is our low tech solution to ensuring that staging is on an identical configuration as production to ensure no gotchas with slight differences in server builds, library versions, etc…

Things had been humming along nicely for about a week when a staff member came rushing into to my office to show me that the production homepage had the tag “STAGING SITE” in the site title. My heart dropped as my mind immediately went to “oh no, the production db is pointing at the staging DB! Has it been that way for a week…. ARGH!!” After a few frantic minutes of checking Drupal and apache site configurations, I realized that the worse case scenario was not the issue. Phew. So it got me thinking that this must be cache related, but how would cache cross sites? Immediately the new piece of memcache came to mind. We are running a single instance for all bins initially.

Doh! That had to be it. So a little Googling and I found this issue in the memcache module queue that was closed. Double Doh! All I had to do was read the README.txt file and the answer was staring me in the face. The cache keys are not always created uniquely with identifiers including URLs/Hostnames nor absolute files paths. So as an example telnet to your default bin.

Let’s look at these. The stats items command lists all the slab and statistics about the items in each slab. Pick a slab number that has some items in it. The slab number is to the right of :items:“. The slab number is 37 in the example below. It indicates there are 3 items in the slab.

Now if we want to see the contents of the items in the slab we issue the stats cachedump <slabnumber> <maxitems> command.

So here we see that in slab 37 there are 3 items. One of those items is cache-variables. Now here is where we have to understand. Drupal has created a cache item with a key of cache-variables. That key has nothing unique about it to let anyone know which of the many drupal sites running it is for. If more than one Drupal site is using this same memcache bin, then it will get/set the same cache item for the variables of the site. Whichever site gets to set this cache item first, the second or third site will use the variables cached by the first site.

In our case, the staging site was hit and set this cache item. Our production site then looked to see if a cache item with the same key existed. It did and so the production site used those values to help generate the requested page. This explains why we saw the site title including the STAGING SITE text on the production site.

Multiple Drupal Sites on same server with MemcacheLet’s get back to the README.txt file in the memcache module. It very explicitly explains that when running multiple sites in the same bin that you need to use the memcache_key_prefix configuration variable in the settings.php that uniquely identifies each site.

Now when I look at the slab containing the cache-variable key, we’ll notice it is prefix with “staging_” which now only the staging site is going to look at. Adding a different prefix configuration to the production site ensures that it too has unique cache item keys.

This is obvious now having found the problem and solution however it definitely was one of those “Doh” moments. Hopefully this will help someone else.