When doing performance assessment for large and complex sites to assess why they are not fast or scalable, we often run into cases where modules intentionally disable the Drupal page cache.

Depending on how often it happens and for which pages, disabling the page cache can negatively impact the site's performance, be that in scalability, or speed of serving pages.

How to inspect code for page cache disabling

If you want to inspect a module to see if it disables the page cache, search its code for something like the following:

// Recommended way of disabling the cache in Drupal 7.x
drupal_page_is_cacheable(FALSE);

Or:

$GLOBALS['conf']['cache'] = 0;

Or:

$GLOBALS['conf']['cache'] = CACHE_DISABLED;

Or:

$conf['cache'] = FALSE;

Modules that disable the page cache

We have found the following modules that disable the page cache in some cases:

Bibliography Module

Bibliography module

In biblio_init(), the module disables the page cache if someone is visiting a certain URL, such as "biblio/*" or "publications/*", depending on how the module is configured.

if ($user->uid === 0) { 
  // Prevent caching of biblio pages for anonymous users
  // so session variables work and thus filering works
  $base = variable_get('biblio_base', 'biblio');
  if (drupal_match_path($_GET['q'], "$base\n$base/*"))
    $conf['cache'] = FALSE;
}

Flag Module

Flag module

This code in flag/includes/flag_handler_relationships.inc

if (array_search(DRUPAL_ANONYMOUS_RID, $flag->roles['flag']) !== FALSE) {
  // Disable page caching for anonymous users.
  drupal_page_is_cacheable(FALSE);

Or in Drupal 6.x:

if (array_search(DRUPAL_ANONYMOUS_RID, $flag->roles['flag']) !== FALSE) {
  // Disable page caching for anonymous users.
  $GLOBALS['conf']['cache'] = 0;

Invite Module

Invite module

case 'user_register':
  // In order to prevent caching of the preset 
  // e-mail address, we have to disable caching 
  // for user/register.
  $GLOBALS['conf']['cache'] = CACHE_DISABLED;

CAPTCHA Module

CAPTCHA module

The CAPTCHA module disables the cache wherever a CAPTCHA form is displayed, be that in a comment or on the login form.

This is done via the hook_element_info() which sets a callback in the function captcha_element_process().

If you find other modules that are commonly used, please post a comment below about it.

Comments

Tue, 2013/02/19 - 02:53

Assigning a value to $_SESSION also disables the cache for anonymous users if you're not too careful: once a session cookie is set, the _drupal_bootstrap_page_cache() won't load the cached page.

Another way of checking if you're pages get cached is looking for the "X-Drupal-Cache" HTTP header. If page caching is enabled, it'll indicate performance with a "HIT" or "MISS".

Tue, 2013/02/19 - 17:18

That is true for Drupal 7.x and Pressflow 6.x.

This is not the case with Drupal 6.x though.

Thu, 2013/02/21 - 10:25

True, but if you are running Drupal 6 and having performance issues, one of the very first things you should do is switch to Pressflow 6 anyway.

Thu, 2013/02/21 - 11:40

As a general rule, yes, Pressflow 6 is better than Drupal 6 in terms of scalability.

However, there are notable exceptions.

We have consulted for clients who use Pressflow 6 with modules that cause cookies and sessions. For these clients switching back from Pressflow to Drupal solved their slowness issues!

Tue, 2013/02/19 - 04:00

Some more are:

Mollom

Disables the cache when it adds a CAPTCHA to a form:

mollom_form_add_captcha()

Webform

Disables the cache when viewing your own webform submissions listing as anonymous.
Disables the cache when anonymous users view or edit a webform submission.
Disables the cache for anonymous users who have the 'access own webform submissions' permission when they are viewing a webform node or viewing a webform completion page (ie. node/NID/done).

webform_disable_page_cache()

Tue, 2013/02/19 - 17:07

Thanks for sharing these.

Tue, 2013/02/19 - 07:52

I am working on precisely such a large and complex site at the moment and it's incredibly slow even on a physical dedicated server with 3 GB RAM, so this is really useful.

In fact, we are using two of the three modules mentioned here - Flag and Captcha.

My question is, how does one get around the problem as they are both required modules for the site?

Thanks in advance.

Tue, 2013/02/19 - 16:39

If you use captcha for comment forms, set them to appear on separate pages. This way, the node page will still be cached.

Tue, 2013/02/19 - 17:06

Absolutely correct!

We recommended just that for a client that had a very large site and had CAPTCHA on them to deter spammers.

Another option is using Mollom, which will try to determine whether the comment is spam by other methods before falling back to a CAPTCHA.

Wed, 2013/11/06 - 13:47

You may also want to look at the Honeypot module as an alternative to CAPTCHA. We couldn't use CAPTCHA due to accessibility requirements, and investigated the Honeypot module as a far less robust, but free, alternative to Mollom. We've been pleasantly surprised as we've had it in place for over 6 months and have had zero complaints of spam from form recipients, and also zero complaints of legitimate form submissions being blocked.

Pablo

Pages

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting