Varnish shouldn't need a cache.inc - or is the D7 varnish module providing one now?
If using varnish for page caching, you have a choice of keeping cache entries in memcache too, or using DrupalFakeCache so that Drupal doesn't write cached pages back at all (you can also use http://drupal.org/project/devnull for that since DrupaFakeCache isn't completely a null implementation, that's not a joke, it's actually a bit useful!).
cache_bootstrap is designed for APC and similar. However if you are running more than one web server, you will need to figure out what to do about cache coherency since clears will only happen on the local APC instance. I started http://drupal.org/sandbox/catch/1153584 to work on approaches to that issue but haven't found the time to actually work on an implementation at all.
With the cache bin, keep an eye on how much goes in there - it may get too big for what you'd expect to go into APC.
If you're using page_cache_invoke_hooks, also set page_cache_without_database.
honestly trying to get work done here. not fooling with jokes.
i've no clue whether you're serious about dev/null usage or not.
presuming my time's being wasted, for any others that get similarly hoodwinked, take a look at: http://drupal.org/project/bad_judgement. a "Novelty" module? "Trust me. You shouldn't be enabling this module. But if you do enable this module, you shouldn't be enabling the module that requires this module either."
However, after posting it, I realised there is a genuine usage for the dev/null cache backend - since when using varnish, you may not want Drupal to write the page cache back to anywhere internally, and there isn't a proper one anywhere else. See these two core issues, http://drupal.org/node/627496 and http://drupal.org/node/1082328
You should not use anything else in that project. Since the cache backend can be used without installing any modules, there is no actual dependency on bad judgement to use it.
Yes like that. DrupalFakeCache will delete rows from the database on cache clears (because it is really used for the installer and the installer needs hacks), whereas dev/null really does no nothing at all.
to your point ... "using" page_cache_invoke_hooks would be "=TRUE", right? i.e., with page_cache_invoke_hooks=FALSE, does 'page_cache_without_database' need to be set?
I actually can't remember, but you should double check in bootstrap.inc yourself. These are very poorly documented.
iiuc, you specifically mean more than one server instance, right? not 'just' multisites, or multiple-threads?
More than one server instance. The only issue with multi-site is again watching total cache size, since if you have 64mb allocated to user caching in APC, that is shared across your whole server.
atm, @ Pressflow6 installs, we've only Varnish & memcache in use -- no Drupal-specific APC, where our single-bin memcache config includes (settings.php),
assuming that memcached module is ready for D7 deployment (pretty sure that's NOT the case, yet), is there any advantage to using APC at all? even for bootstrap?
iiuc, this may be sufficient/optimal ... particularly for 'single(default)-bin' memcache?
Since you are running memcache on localhost there will be almost no benefit to using APC for some bins. APC will only be significantly faster than memcache if memcache is running on another server.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
APC is usually faster than Memcache, or at least it used to be. I remember someone who did benchmarks on it and had a blog post. I thought it was on 2bits.com, but I couldn't find it.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
Sure APC is faster, but how many cache_gets are there to cache_bootstrap per page? (I'm guessing it's just one). Lets say on localhost a cache_get to memcache is .5ms and a cache_get from APC is .05ms. Your page is not going to load any faster. I think you'd find a similar conclusion when looking at it from a scalability point of view. If Memcache is running on another server then there may be a small benefit, but only on a very high traffic site (like examiner.com scale).
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
If you are on the one-box infrastructure, APC actually has an advantage beyond read/write speed: it can cache PHP data structures natively rather than as serialized text. This eliminates the unserialize() overhead, which can be significant if you have a huge menu tree, variables table, etc.
However APC does not work if you need to scale horizontally, so it's usually out of the question if you have real ambitions.
It looks like 3. I just checked on a rather vanilla D7 install (devel and admin_menu only installed modules). One thing I do see is that system_list is pulled from there and that's a rather large cache (almost 74k on mine). With what JoshK said, I could see that adding into some processing time given the overhead of unserialize when using memcached. It's one of those things i would love to see benchmarked though.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
Yes on larger sites if you do some PHP profiling, unserialize() is usually one of the top 5 or 10 most expensive functions. I had opened an issue at one point to use JSON instead but it won't work since sometimes complex objects are stored in the cache.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Comments
Varnish shouldn't need a
Varnish shouldn't need a cache.inc - or is the D7 varnish module providing one now?
If using varnish for page caching, you have a choice of keeping cache entries in memcache too, or using DrupalFakeCache so that Drupal doesn't write cached pages back at all (you can also use http://drupal.org/project/devnull for that since DrupaFakeCache isn't completely a null implementation, that's not a joke, it's actually a bit useful!).
cache_bootstrap is designed for APC and similar. However if you are running more than one web server, you will need to figure out what to do about cache coherency since clears will only happen on the local APC instance. I started http://drupal.org/sandbox/catch/1153584 to work on approaches to that issue but haven't found the time to actually work on an implementation at all.
With the cache bin, keep an eye on how much goes in there - it may get too big for what you'd expect to go into APC.
If you're using page_cache_invoke_hooks, also set page_cache_without_database.
re: "not a joke" ... and the
re: "not a joke" ...
and the dependency of 'devnull' on 'bad_judgement' is ... ?
I started it as a joke, then
I started it as a joke, then realised it has the potential to be a useful module, which makes the joke better IMO :)
By the way I saw you posted an issue, I'll have a look later.
honestly trying to get work
honestly trying to get work done here. not fooling with jokes.
i've no clue whether you're serious about dev/null usage or not.
presuming my time's being wasted, for any others that get similarly hoodwinked, take a look at: http://drupal.org/project/bad_judgement. a "Novelty" module? "Trust me. You shouldn't be enabling this module. But if you do enable this module, you shouldn't be enabling the module that requires this module either."
uh-huh.
Well you're getting free
Well you're getting free advice in my limited spare time, so should be able to put up with some humour.
I started the dev/null project as a joke, based on this video: http://renato.mascardo.com/2010/09/30/devnull-db-is-fast-as-hell/
However, after posting it, I realised there is a genuine usage for the dev/null cache backend - since when using varnish, you may not want Drupal to write the page cache back to anywhere internally, and there isn't a proper one anywhere else. See these two core issues, http://drupal.org/node/627496 and http://drupal.org/node/1082328
You should not use anything else in that project. Since the cache backend can be used without installing any modules, there is no actual dependency on bad judgement to use it.
_
_
$conf['cache_class_cache'] =
$conf['cache_class_cache'] = 'DrupalFakeCache';Yes like that. DrupalFakeCache will delete rows from the database on cache clears (because it is really used for the installer and the installer needs hacks), whereas dev/null really does no nothing at all.
I actually can't remember, but you should double check in bootstrap.inc yourself. These are very poorly documented.
More than one server instance. The only issue with multi-site is again watching total cache size, since if you have 64mb allocated to user caching in APC, that is shared across your whole server.
atm, @ Pressflow6 installs,
atm, @ Pressflow6 installs, we've only Varnish & memcache in use -- no Drupal-specific APC, where our single-bin memcache config includes (settings.php),
...$conf += array(
'cache_inc' => './sites/all/modules/memcache/memcache.inc',
'session_inc' => './sites/all/modules/memcache/memcache-session.inc',
'lock_inc' => './sites/all/modules/memcache/memcache-lock.inc',
'memcache_servers' => array('127.0.0.1:11211' => 'default',),
'memcache_bins' => array('cache' => 'default',),
...
assuming that memcached module is ready for D7 deployment (pretty sure that's NOT the case, yet), is there any advantage to using APC at all? even for bootstrap?
iiuc, this may be sufficient/optimal ... particularly for 'single(default)-bin' memcache?
...$conf['cache_backends'] = array(
'sites/all/modules/devnull/devnull-cache.inc',
'sites/all/modules/memcache/memcache.inc',
'sites/all/modules/varnish/varnish.cache.inc',
);
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['cache_class_cache'] = 'DevNuLLCache';
$conf['cache_class_cache_page'] = 'VarnishCache';
$conf['page_cache_without_database'] = TRUE;
$conf['page_cache_invoke_hooks'] = FALSE;
...
Since you are running
Since you are running memcache on localhost there will be almost no benefit to using APC for some bins. APC will only be significantly faster than memcache if memcache is running on another server.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
APC is usually faster than
APC is usually faster than Memcache, or at least it used to be. I remember someone who did benchmarks on it and had a blog post. I thought it was on 2bits.com, but I couldn't find it.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
Sure APC is faster, but how
Sure APC is faster, but how many cache_gets are there to cache_bootstrap per page? (I'm guessing it's just one). Lets say on localhost a cache_get to memcache is .5ms and a cache_get from APC is .05ms. Your page is not going to load any faster. I think you'd find a similar conclusion when looking at it from a scalability point of view. If Memcache is running on another server then there may be a small benefit, but only on a very high traffic site (like examiner.com scale).
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
serialization overhead
If you are on the one-box infrastructure, APC actually has an advantage beyond read/write speed: it can cache PHP data structures natively rather than as serialized text. This eliminates the unserialize() overhead, which can be significant if you have a huge menu tree, variables table, etc.
However APC does not work if you need to scale horizontally, so it's usually out of the question if you have real ambitions.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
It looks like 3. I just
It looks like 3. I just checked on a rather vanilla D7 install (devel and admin_menu only installed modules). One thing I do see is that system_list is pulled from there and that's a rather large cache (almost 74k on mine). With what JoshK said, I could see that adding into some processing time given the overhead of unserialize when using memcached. It's one of those things i would love to see benchmarked though.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
The size of that the
The size of that the system_list() cache is a bug, have an in-progress patch at http://drupal.org/node/1061924
Yes on larger sites if you do
Yes on larger sites if you do some PHP profiling, unserialize() is usually one of the top 5 or 10 most expensive functions. I had opened an issue at one point to use JSON instead but it won't work since sometimes complex objects are stored in the cache.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
_
_