How about this then? Not tested too much but seems to work.

$conf['session_inc'] = './sites/all/modules/cache/session.inc';
    $conf['cache_settings'] = array(
      'engines' => array(
        'db-engine' => array(
          'engine' => 'database',
        ),
		'xc-engine' => array(
          'engine' => 'xcache',
        ),
		'fl-engine' => array(
          'engine' => 'file',
        ),
      ),
      'schemas' => array(
        'full-schema' => array(
		  'xc-engine',
		  'db-engine',
		  'fl-engine',
        ),
      ),
      'bins' => array(
        'default' => 'full-schema',
	'cache' => 'full-schema',
        'cache_form'    => 'full-schema',
        'cache_filter'  => 'full-schema',
      ),
    );

My aim is to ask whatever to Xcache (mmap) first, then try slower db, then try even slower file, then fallback to slowest fresh copy.

I am trying to lower Xcache RAM consumption to a reasonable limit without sacrificing responsiveness too much.

Can cache query pass beyond "db-engine" with this schema? Or is this config is ridiculous on the whole?

Tx for this great module by the way.

Comments

chawl’s picture

chawl commented

Oops, copy-paste disorder :P
first line has:

$conf['cache_inc'] = './sites/all/modules/cache/cache.inc';
doq’s picture

doq commented

Well, it should be tested.

But some considerations:

If you put 3 different engines into schemes then whenever cache is written (cache_set, cache_clear_all) it will be executed for all these three. So it might degrade performance under some circumstances.

Xcache: I usually use Xcache/APC for only one table: cache (most of its variables are used on every page request (variable, theme_registry etc.)). And its size is always constant, around 1-2MB (so I can ensure it will get cache hit 99.9%). If cache is not found in xcache then implementation will try to find cache in db engine. If found it won't be written back to Xcache. Just when cache_set/cache_clear_all occurs.

chawl’s picture

chawl commented

You are right. As I have observed, file writing indeed impacts the performance and it seems that the cache files have never been accessed. Then I disabled it and avoided the expensive file write operations.

For the Xcache part, sometimes Apache needs a restart and Xcache dies with it unfortunately, but as db cache tables remains intact, Drupal seems to recover the restart more rapidly, though I am not sure if db cache remains valid thereafter and if this effect is not a placebo.

Sorry that I am working on a production server and I can not make extensive tests, but Xcache->db schema seems not to be bad at all. Our load averages dropped significantly, and I am not worrying too much if Xcache has a cached copy or not with the confidence that at least db has one.

This module is a lifesaver anyway, tx :)

doq’s picture

doq commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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