Last updated February 15, 2015. Created on December 19, 2013.
Edited by znerol. Log in to edit this page.

Rendered pages are cached in the database when using the Authcache Builtin Storage Backend module by default. As a result Drupal still needs to access the database when delivering a page from the cache. It is possible to swap out the cache handler with an implementation which is better suited for volatile key-value collections and avoid the database completely when delivering pages from the cache. This helps on cutting back database size and traffic and reduces response times for cache-hits by at least one half.

In Drupal 7 configuration (aka variables) is stored in the database. It follows that when there is no database connection, the configuration will not be available. This means that settings which were customized using administrative pages (e.g. on Administration » Configuration » Development » Performance) will be at their default state when cached pages are delivered. Therefore it is important to hard-code settings which influence cache delivery directly in settings.php.

On sites with a great amount of content, the page cache may grow quite large. Therefore it is necessary to assess storage needs before deciding which cache backend is suitable (e.g. in-memory vs on-disk). When upgrading from the database cache, the size of the current cache can be estimated by inspecting the cache_page table in the database.

Shared settings

<?php
// FIXME: Put backend-specific settings here, see the respective sections about Memcache, MongoDB and Redis for suitable fragments.

/**
 * When serving cached pages, do not bother connecting to the database.
 */
$conf['authcache_builtin_cache_without_database'] = TRUE;

/**
 * All customized settings influencing page delivery need to be set here.
 */

// Deliver gzip compressed pages if possible
$conf['page_compression'] = 1;

// Allow browsers to store the page for up to 10 minutes
$conf['page_cache_maximum_age'] = 600;

/**
 * Required configuration for Authcache Builtin Storage Backend.
 */
$conf['cache_backends'][] = 'sites/all/modules/authcache/authcache.cache.inc';
$conf['cache_backends'][] = 'sites/all/modules/authcache/modules/authcache_builtin/authcache_builtin.cache.inc';
?>

Configure Memcache API

This section shows a sample settings.php configuration for the memcache module:

<?php
/**
 * Use Memcache for the page cache and authcache keys.
 */
$conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';
$conf['cache_class_cache_page'] = 'MemCacheDrupal';
$conf['cache_class_cache_authcache_key'] = 'MemCacheDrupal';
$conf['cache_class_cache_bootstrap'] = 'MemCacheDrupal';

$conf['memcache_servers'] = array('127.0.0.1:11211' => 'default');

// FIXME: Put shared settings here (see above).
?>

Note, Memcache API and Integration up to and including 7.x-1.3 suffers from #2361001: Page cache never expires if authcache_builtin_cache_without_database is enabled. Make sure to install an up-to-date version of the module.

Configure MongoDB

This section shows a sample settings.php configuration for the MongoDB module:

<?php
/**
 * Use MongoDB for the page cache and authcache keys.
 */
$conf['cache_backends'][] = 'sites/all/modules/mongodb/mongodb_cache/mongodb_cache.inc';
$conf['cache_class_cache_page'] = 'DrupalMongoDBCache';
$conf['cache_class_cache_authcache_key'] = 'DrupalMongoDBCache';

// FIXME: Put shared settings here (see above).
?>

Configure Redis

This section shows a sample settings.php configuration for the Redis module:

<?php
/**
 * Use Redis for the page cache and authcache keys.
 */
$conf['redis_client_interface'] = 'PhpRedis';

$conf['cache_backends'][] = 'sites/all/modules/redis/redis.autoload.inc';
$conf['cache_class_cache_page'] = 'Redis_Cache';
$conf['cache_class_cache_authcache_key'] = 'Redis_Cache';

// FIXME: Put shared settings here (see above).
?>

Note, Redis 7.x-2.12 suffers from #2354181: Fatal error with $conf['page_cache_without_database'] = TRUE.

Configure File Cache

This section shows a sample settings.php configuration for the File Cache module:

<?php
/**
 * Use File Cache for the page cache and authcache keys.
 */
$conf['cache_backends'][] = 'sites/all/modules/filecache/filecache.inc';
$conf['filecache_directory'] = '/full/path/to/your/file-cache/directory';

$conf['cache_class_cache_page'] = 'DrupalFileCache';
$conf['cache_class_cache_authcache_key'] = 'DrupalFileCache';

// FIXME: Put shared settings here (see above).
?>

When running on Apache it is not necessary to specify the filecache_directory. However it still might come in handy in multi-site setups like outlined in the file-cache README.txt:

Here is a example of a simple configuration that works for multi-site deployment. conf_path() always returns "sites/SITENAME" and this is used to retrieve SITENAME. File Cache creates directory if it doesn't exist and there should be no problem with permissions since it's in /tmp.

<?php
$conf
['filecache_directory'] = '/tmp/filecache-' . substr(conf_path(), 6);
?>

Verify the settings

In order to verify whether the settings are picked up, log into the site as an administrator and navigate to Administration » Reports » Status report. There should be a line specifying which cache class is used.

Status report with cache class being used by Authcache Bultin Storage Backend

When Authcache Debug is enabled, this information is also visible in the debug widget.

Cache class shown in debug widget

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

ohthehugemanatee’s picture

I'm a bit confused about the workflow and keys that authcache uses for page fragments. Would there be a speedup in putting Authcache fragments into Varnish, like this?

$conf['cache_class_cache_page'] = 'VarnishCache';
$conf['cache_class_cache_authcache_key'] = 'VarnishCache';

For example: on a page request for http://example.com/node/5, Varnish sends the cached page to the browser, including embedded Authcache JS. The JS makes a series of callbacks to http://example.com/authcache.php for the fragments. If we're storing the fragments in Varnish, can Varnish fulfill those callbacks without starting the backend? Or are they reliant on authcache.php to compute the key?

There's an awesome speedup already in keeping the fragments in memcache etc, but I'm wondering if we can take the backend out of the equation entirely.

You never REALLY learn to swear until you own a computer.

znerol’s picture

Authcache fragments most often are unique for each user (e.g. shopping cart, CSRF token, user profile information). Therefore the benefit of caching them server-side is in most cases rather small. Rather Authcache makes sure that fragments loaded via Ajax are stored in the browser cache.

Still if you think that storing fragments on the server is necessary and you want to use Varnish for that, then set-up Varnish and ESI following the respective documentation. Note that the VarnishCache does not contain any code for storing/retrieving cached pages. It is only used to mimic Drupals cache-clear behavior. Do not use it for anything different than the page cache.