Caching layers for Drupal: what to use when

Drupal has one of the most sophisticated caching systems of any CMS, and that is part of why caching conversations get confusing. Page cache, dynamic page cache, render cache, cache bins, Varnish, CDN, Redis, Memcached: they are all real, they all do different jobs, and a site rarely needs all of them configured the same way. This article lays out the layers from the visitor inward, then explains what to use for different kinds of sites.

The layers, from the visitor inward

How Drupal keeps caches accurate

Caching is only safe if stale content is cleared at the right moment. Drupal attaches metadata to everything it renders:

• Cache tags say what content a piece of output depends on, such as node:42. When node 42 changes, everything tagged with it is invalidated, and nothing else.
• Cache contexts say what the output varies by, such as the user's role, language, or URL.
• Max-age says how long the output stays valid.

This lets Drupal invalidate precisely rather than clearing everything. The Purge module family extends the same tags to Varnish and CDNs, so editing one page clears just the cached pages that show it, all the way out to the edge.

A common pitfall: a single block that sets max-age to zero, often a custom block showing something "live", makes the entire page uncacheable for the Internal Page Cache. If anonymous pages are slow, look for that first.

Redis or Memcached?

By default Drupal stores its cache bins in database tables, which adds load to the database and grows those tables quickly on busy sites. Moving the cache backend to memory is one of the most effective changes you can make. Both options work well:

• Memcached is simple, fast, and purely a cache. It is a long-standing choice for Drupal and does one job well.
• Redis is equally fast for caching and also supports persistence and richer data types, so it can hold other things such as queues or sessions. It is widely available as a managed cloud service.

For most new builds, Redis is the practical default because the same service can cover several needs. If a site already runs well on Memcached, there is rarely a reason to switch. What matters more is sizing the cache so it is not constantly evicting entries, and giving each site its own key prefix if several share one service.

What to use for which site

Signs a layer is not doing its job

• Anonymous pages show no X-Drupal-Cache: HIT or CDN hit headers.
• The cache_ tables in the database are large and busy.
• Editors wait for changes to appear, or someone clears all caches several times a day.

When in doubt, measure before tuning. Response headers, the cache hit ratio in Redis or Memcached, and page timings for anonymous and logged-in users show which layer is underperforming, so effort goes where it makes a difference.

How eWay configures Drupal caching

eWay chooses caching layers per workload rather than applying one template. Typically that is a CDN with tag-based purging in front, Drupal's page and dynamic caches tuned, and Redis or Memcached as the cache backend, sized and monitored for hit ratio and evictions. eWay also audits custom code for cache metadata problems that quietly disable caching.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• Whether the issue is stale content or slow pages, and for anonymous or logged-in users
• Example URLs and response headers

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: object caching with Redis and page caching and CDN behavior. More on our Drupal page.