Does this module need a prefix for multisites? If so, how? I noticed that an APC flush was needed to avert stale caches after installing a second site. Thanks for any info!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

threading_signals’s picture

For a reminder, I think before upgrading to a minor version (d7.x to d7.y), the cache may have to be flushed. Correct me if I'm wrong.

pounard’s picture

It seems the code uses the $_SERVER['HTTP_HOST'] variable to build APC cache entry keys, so it should work gracefully using multiple Drupal sites on the same APC shared memory.

R.Muilwijk’s picture

The HTTP HOST is used.. I'm keeping this issue open to see or someone comes up with a better solution to prefix for multi sites.

pounard’s picture

@#3 That's quite good the HTTP_HOST, each site has its own, am I right? It may cause some problems (the same Drupal instance accessible from multiple hostnames). You might use the site signature instead, or leave the prefix configurable in the settings.php file.

threading_signals’s picture

Well, I took a look at user cache entries with domain access enabled. I see for the other sites that cache_* (e.g. cache_bootstrap) entries under the apc stats page are getting hits, but they don't have domain access enabled. The domain access enabled sites are using everything except the user cache entries. All of these sites are part of a multi-site install.

Let's say that this config in settings.php was used:

$conf['cache_backends'] = array('sites/all/modules/apc/drupal_apc_cache.inc');
$conf['cache_default_class'] = 'DrupalAPCCache';

Essentially, what does domain access need to do, to work with apc? I'll link up an issue in domain access, or re-edit here to mark the progression of this issue.

The original question had domain access in mind as well, used with multi-sites.

threading_signals’s picture

Title: Need multisite prefix info » Need configuration info for domain access.

No issues with multi-site install, but working on domain access user cache entries resolution.

threading_signals’s picture

Ok, the example here http://drupal.org/node/805164:

$thishost = $_SERVER[HTTP_HOST];
$thishost = str_replace(".", "_", $thishost);
$conf['cache_inc'] = './sites/all/modules/cacherouter/cacherouter.inc';
$conf['cacherouter'] = array(
'default' => array(
'engine' => 'file', // apc, memcache, db, file, eacc or xcache
'server' => array(), // memcached (host:port, e.g., 'localhost:11211')
'shared' => TRUE, // memcached shared single process
'prefix' => $thishost, // cache key prefix (for multiple sites)
'path' => 'cache/cacherouter/'.$thishost, // file engine cache location
'static' => FALSE, // static array cache (advanced)
'fast_cache' => FALSE,),);

...is for D6 module, but how to enable prefix for the cacherouter for user cache? [which should make it work with domain access...? since multi-site works fine, and domain is what I need for internationalization]

threading_signals’s picture

I need a D7 equivalent of:

'prefix' => $thishost, // cache key prefix (for domain access)

R.Muilwijk’s picture

What doet the domain module do? Set the $db_prefix for certain cache tables?

threading_signals’s picture

Domain access: http://drupal.org/project/domain

Like multi-sites for affiliate sites, but without making folders, and useful for sites that use additional languages.

As for the technical question, I believe they do not use $db_prefix, but use module specific variables. The manual may have more info on that part.

regilero’s picture

subscribing,

Other cache backends can be prefixed with settings (directory prefix for filecache, 'memcache_key_prefix' in memcached). Apc should provide a clean way to prefix entires via the $conf array in settings. So that no one would need to make hard and heavy tests on multisites installations to ensure apc is not merging caches between different websites (think about drush usage without --uri option, or sites using same instance based on master domain match)

examples where $_SERVER['SERVER_NAME'] is bad and a configuration prefix better:
* my website runs under a chain of proxy, the real used name (for final user) is the first name (coma separated) of HTTP_X_FORWARDED_HOST, and can be different for different users (white-mark). Using SERVER_NAME (which is always the same) will make the cache being mutualized by all used domains, so very bad for cache_page bin. I would like to use the extracted final domain and put that in a cache prefix configuration setting.
* inverted problem: using drupal multisite with subdirectory, www.example.com, foo.example.com and bar.example.com using the same sites/example.com tree, I'll maybe want to share some caches between these 3 websites, here I can't, SERVER_NAME is different, the cache keys will be different. I would like to use the 'example.com' as cache prefix.

pounard’s picture

Title: Need configuration info for domain access. » APC backend needs to be able to use a configurable prefix to avoid sites key collision
Version: 7.x-1.0-beta2 » 7.x-1.x-dev
Category: support » bug
Status: Active » Needs review
FileSize
2.65 KB

Did a patch fixing this behavior. With it you can use:

$conf['cache_prefix'] = 'my_site_prefix_';

In your settings.php file in order to fix the APC key prefix for one site.

I'm also going to file an issue to take over this module ownership and maintenance because the original owner didn't answer to bug reports since a long time, and issue releases seems frozen since a long time. Oh did not notice that the latest release is from June this year.

R.Muilwijk’s picture

Been reading everything.. just have not had time. Expect commits soon

pounard’s picture

Don't worry. I'm being really active right now because I'm working (a lot) with various cache backends: expect to see more patches from me soon.

R.Muilwijk’s picture

Is the cache_prefix a variable used by more modules? Or should we move this to a apc_cache_prefix variable?

pounard’s picture

I did intentionally made this variable being common with the one I use for my own cache backends, this allows to use only one common variable, makes sense to me.

What do you think?

R.Muilwijk’s picture

Memcache used this function:

function dmemcache_key($key, $bin = 'cache') {
  $prefix = '';
  if ($prefix = variable_get('memcache_key_prefix', '')) {
    $prefix .= '-';
  }
  // When simpletest is running, emulate the simpletest database prefix here
  // to avoid the child site setting cache entries in the parent site.
  if (isset($GLOBALS['drupal_test_info']['test_run_id'])) {
    $prefix .= $GLOBALS['drupal_test_info']['test_run_id'];
  }
  $full_key = urlencode($prefix . $bin . '-' . $key);

  // Memcache only supports key lengths up to 250 bytes.  If we have generated
  // a longer key, hash it with sha1 which will shrink the key down to 40 bytes
  // while still keeping it unique.
  if (strlen($full_key) > 250) {
    $full_key = $prefix . $bin . '-' . sha1($key);
  }

  return $full_key;
}

So I'm not really sure what to do..

pounard’s picture

I was about proposing memcache to merge the variable, how'd you feel about asking them and wait for their answer?

R.Muilwijk’s picture

Ok, I'll wait for that for now! People can use the patch if they need this functionality which is only a minor group because the HTTP_HOST key suits most of the solutions.

dropbydrop’s picture

+1

Dustin Bons’s picture

+1

pounard’s picture

I opened #1324812: Unify cache bin prefix: proposal to unified convention into memcache project, since it's one of the most used.
I hope they will react fast.

pounard’s picture

Hello again, this issue needs work, definitely. Memcache people seems to agree with the proposal I made there, I'm ready to provide a patch for this module.

See http://drupal.org/node/1324812#comment-5174946 comment, I guess I definitely would provide the exact same code to the APC backend if I was to propose a patch.

@R.Muilwijk Are you OK?

pounard’s picture

I did a patch that uses the same algorithm as the Redis one. Ideally we could even share this code, but in order for the backends to remain independent this 10 lines of cut/paste is not really a problem.

R.Muilwijk’s picture

Status: Needs review » Fixed

Committed to head.

pounard’s picture

Oh nice, thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Nor4a’s picture

Thanks - this was really necessary peace of config as allmoast all our projects has multiple domains. Till now - if I wanted to clear the caches - i needed to do it for all of the domains - e.g. logging in in each of the domain and run "flush caches". Or restart the httpd - which is not realy good for production server running ~40 web-sites :D

melsi’s picture

I'm not sure if this is just a problem for me but the apc-unified-bin-prefix patch seems to start working a little too late:

I set the variable site_prefix to a specific string ('d7'), cleared the apc user cache and reloaded the page.
That resulted in the following apc user cache entries:

localhost::cache_bootstrap::variables [...]
localhost::cache_bootstrap::system_list [...]
localhost::cache_bootstrap::module_implements [...]
localhost::cache_bootstrap::lookup_cache [...]
localhost::cache_bootstrap::hook_info [...]
localhost::cache_bootstrap::bootstrap_modules [...]
d7::cache_menu::menu_custom [...]
[...]

I guess that since the variables get loaded at a later state the entries are still created with the hostname.

That might not be a problem with real multisite installations but it is for me as I have one VHost with multiple independant drupal installations within which crash every time there are "shared" entries like localhost. When I remove these localhost entries (after each page load), everything works again.

melsi’s picture

I got it working for me using a simple trick: As long as the variable entry returns empty, use something to distinguish this installation; the installation path
(see attached patch)

melsi’s picture

I'm writing an issue, just fyi (because this one is old and closed) ^^