Note for Acquia-hosted websites
Cloud Platform customers use Varnish cache. For more information about Varnish and how to configure Varnish cache for your Cloud Platform website, see Using Varnish.
Cloud Platform subscriptions support Memcached, which does not consider cron to be a cache-clearing event. If you use Memcached, your pages does not regenerate after cron. For more information, see Using Memcached.
When configuring external caching for your Drupal site, the following important settings may cause trouble for users, if not properly understood:
To find the settings, in the Admin menu, go to Configuration > Performance (see the site path.)
The minimum cache lifetime prevents Drupal from clearing webpages and block caches for a period of time after making changes which means Drupal will not regenerate webpages until at least the period of time has passed, and a cache-clearing event has taken place. Webpages are not necessarily regenerated after the minimum cache lifetime has passed.
The default value for the minimum cache lifetime is
none, which means
the default lifetime is
0 seconds. Unless you are familiar with configuring
cache, and you have different requirements, best practices would have you
keep the setting as
If something triggers the cache to clear, and the minimum cache lifetime
is set to a value greater than
none, the combination can cause a cache
stampede. The problem occurs when a cached webpage is no longer cached, and
several website visitors request the webpage within a short time frame. When
servers try to render the webpage simultaneously, none of them will
rebuild or re-cache the webpage, because every attempt to do so will time out.
The server timeouts could result in downtime for your website.
Cloud Platform customers should always set minimum cache lifetime to 0, unless specific circumstances dictate otherwise. Setting the minimum cache lifetime to a non-zero value can cause issues with Varnish.
When a Drupal website’s cron interval is set to its default, the cron
interval will clear the cache routinely, which could result in downtime.
The default Drupal 7 cron (Poor man’s cron) is enabled by default, and you
should disable it, setting the run time to
Never. To disable the default
Drupal 7 cron on your website, in the Admin menu, go to Configuration >
System > Cron
Note for Cloud Platform customers
Use the Cloud > Cron page for scheduled tasks, rather than the default Drupal 7 Cron or any of the contributed Cron modules, such as Elysia Cron or Ultimate Cron. Relying on Cloud Platform ensures Cron tasks run on the schedule you specify, and not when visiting the website. For more information, see Using scheduled jobs to support your application. If you must use Elysia cron, see Elysia cron on Cloud Platform.
Expiration of cached pages refers to the maximum time a webpage can remain in
the cache. If you set the expiration of cached pages to
0 seconds which
is the maximum-age header Drupal sends to the proxy server, the pages will
not be cached. A reasonable setting is
6-12 hours. Often misinterpreted,
expiration of cached pages does not mean the webpage will regenerate after
the amount of time you select—the term means, after the period of
time, the cache checks with Drupal to see if a new version of the webpage
exists. The webpage will regenerate after a cache-clearing event happens.
Depending on the content they contain, you may want to set the cache maximum age for specific webpages. For example, if you have a routinely updated news section, you may want to set a brief cache lifetime as opposed to the longer lifetime for static content. For more information, see Set max-age headers for specific webpages, files, or paths.
The ESI, or Edge Side Includes, module is not recommended. The module is useful for small pieces of permanently cached content. In most cases, users want to have the small section of content uncached, which bootstraps Drupal, defeats the purpose of Varnish, and other caching mechanisms. In various use cases, ESI has a negative impact on system performance.