16

On a Debian Jessie server (Nginx, PHP 5.6, Zend Opcache), I installed Apcu, Redis, Varnish. I also installed APCu, Chained fast backend, Redis and Varnish modules.

In order to make these caching backends play together with Drupal 7, what is the correct backend for each cache bin?


The documentation says :

Because chained_fast backend will mark all the cache entries in a bin as out-dated for each write to a bin, it is best suited to bins with fewer changes.

How do I take care of that recommendation ? Is that correct to put APCu as $conf['chained_fast']['fast_backend'] or is Redis faster ? Between the 20 and more tables, how can I estimate which cache bin should be set to Redis or APCu? Last, shall I only set cache_page for Varnish or is cache_panels a good candidate also for Varnish if all my pages are built with panels?

At the moment this is my settings.php cache part:

//Cache backends
$conf['cache_backends'][] = 'sites/all/modules/contrib/apcu/apcu.cache.inc';
$conf['cache_backends'][] = 'sites/all/modules/contrib/chained_fast/chained_fast.cache.inc';
$conf['cache_backends'][] = 'sites/all/modules/contrib/varnish/varnish.cache.inc';
$conf['cache_backends'][] = 'sites/all/modules/contrib/redis/redis.autoload.inc';

// Chained fast settings
$conf['chained_fast']['fast_backend'] = 'DrupalAPCuCache';
$conf['cache_default_class'] = 'ChainedFastBackend';

// Related Varnish settings
$conf['reverse_proxy'] = TRUE;
$conf['cache'] = 1;
$conf['block_cache'] = 1;
$conf['cache_lifetime'] = 0;
$conf['page_cache_maximum_age'] = 86400;
$conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';
$conf['reverse_proxy_addresses'] = array('127.0.0.1');
$conf['omit_vary_cookie'] = TRUE;
$conf['page_cache_invoke_hooks'] = FALSE; // Don't bootstrap the database when serving pages from the cache.

// Redis settings
$conf['redis_client_interface'] = 'PhpRedis';
$conf['redis_client_host'] = '127.0.0.1';
$conf['lock_inc'] = 'sites/all/modules/contrib/redis/redis.lock.inc';
$conf['path_inc'] = 'sites/all/modules/contrib/redis/redis.path.inc';

// Cache bins configuration
$conf['cache_prefix'] = 'vts'; // Unique prefix for each site
$conf['cache_class_cache_entity_node'] = 'Redis_Cache';
$conf['cache_class_cache_entity_user'] = 'Redis_Cache';
$conf['cache_class_cache_page'] = 'VarnishCache';
$conf['cache_class_cache_panels'] = 'VarnishCache';
$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';  // The 'cache_form' bin must be assigned to non-volatile storage.
5
  • 2
    To answer the question as it is, we would end up repeating what the documentation for the modules implementing cache back-ends would say. Is there anything in particular that you don't understand? Keep in mind that we cannot answer to "How do I get a performance gain?" as that is too broad.
    – apaderno
    Jan 11, 2017 at 13:25
  • 7
    There's one for each cache bin, named the same as the bin. Look for tables with names starting cache_. Each of those is an answer. Do note that only memcache and apcu are applicable to what you're asking as there are implementations written specifically for Drupal's cache system. Varnish is a different kind of cache and opcache is irrelevant here
    – Clive
    Jan 11, 2017 at 13:47
  • Thanks a lot. @Clive, you said only memcache and apcu are applicable to what you're asking . What about Redis then ? I edited the question.
    – Kojo
    Jan 24, 2017 at 14:33
  • 1
    Yep redis is also commonly used as a cache backend, its blazingly fast but not as nice to interface with as, e.g., mongo (not that mongo is used as a cache backend usually, nor redis as a database, though it's possible, but they're often mentioned in the same breath). Use the Drupal integration module and that won't concern you of course
    – Clive
    Jan 24, 2017 at 15:19
  • 2
    What's the point of using all possible cache backends that ever existed in the universe together ?
    – user26231
    Nov 18, 2018 at 11:38

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.