Caching for availability #

This page is for managers who want the site to stay up when many customers arrive at once, and for the operator who configures the caches. It explains why caching is a reliability measure, which layers Exponential offers, what is on out of the box, and the few rules that keep caches from causing problems of their own. The full technical map is Caching layers and Caches.

Contents #

1. Why caching is a reliability measure
2. The layers in plain words
3. What is on out of the box
4. Protection built into the cache
5. Signed-in customers
6. Clearing caches safely
7. Warming after a clear
8. Checklist

Why caching is a reliability measure #

Every page that is answered from a cache is a page that does not need the database, the template engine or a PHP worker. That has two effects a business cares about:

• Headroom under load. The same server can serve far more visitors when most pages come from a cache, so a traffic spike is less likely to turn into an outage.
• Fewer moving parts per request. The database documentation says it plainly: "Most requests never reach the database" because the response cache, the view cache and the template-block cache answer first (Database support, performance and scaling).

There is a limit to remember: a cached front page can stay green while the database is down. That is why the monitoring advice is to check the administration login page as well (Health checks and monitoring).

The layers in plain words #

From the outside in (Caching layers, the layers at a glance):

The two layers that answer without running the application at all, the static cache and Velocity's response cache, have a page of their own: Static and response cache.

What is on out of the box #

From the shipped settings (Caching layers, checked against settings/site.ini, settings/velocity.ini and settings/querycache.ini):

Setup > System information warns when view caching, template compilation, the template cache or the override cache is switched off, and says to "enable them on production" (System information, health checks).

Protection built into the cache #

The README lists fixes in Exponential 6.0.15 that "apply wherever Exponential runs", on Apache and Nginx as well as Velocity (README, "The part that matters even if you never run Velocity"):

• Conditional requests: "a returning visitor's reload is answered with 202 bytes instead of the whole page, because cached pages now answer conditional requests properly".
• Content-based identity: rebuilding a cache entry that produced identical output "no longer forces every visitor to download it again".
• One rebuild, not a stampede: "when a cached page expires, one request rebuilds it while everyone else is served the existing copy — instead of every visitor present rebuilding it at once". This is what keeps a popular page from overloading the server the moment its cache expires.
• Remembered "not found": "a 'not found' is remembered instead of being rebuilt from scratch every time".

For a business, the third point matters most: the moment a cache expires on a busy page is a classic cause of overload, and Exponential handles it for you.

Signed-in customers #

Customers who are signed in (members, shop customers with an account, editors) see pages that depend on who they are. The Velocity response cache never serves them: "Signed-in visitors are never served from the cache" (settings/velocity.ini, [CacheSettings]). The content view cache still helps them, because it is kept per role and limitations (View cache and cache blocks), and the role-aware HTTP cache can serve signed-in visitors per permission context when it is switched on.

If most of your traffic is signed in (an intranet, a member site, a shop at checkout), plan capacity for rendered pages, not cached ones (Peak traffic planning).

Clearing caches safely #

Caches cause trouble only when they are cleared carelessly. Three rules:

1. Clear the smallest thing that fixes the problem. A settings change needs the INI cache, a template the template cache. "Everything, when unsure" exists, but costs the next visitors a slow page each (Operating a site, clear the right cache).
2. Look first. --dry-run shows what a clear would do and changes nothing.
3. Clear page caches last. "Clear the HTTP and response caches after PHP-FPM or Velocity runs the new code, otherwise a page rendered by the old code in between is stored again" (same page). The deploy command does this in the right order (Graceful deploys).

Large caches are moved aside and deleted afterwards, "so a clear does not make requests wait" (Cache clears that move directories aside).

Warming after a clear #

After a clear or a deploy "the first visitor pays for the render". Warm the pages yourself (Operating a site, warm the site):

php bin/php/preload.php --apply --siteaccess=site --allow-root-user

Use the name of your own public siteaccess. The same is available in the administration as Preload Sites (Preloading caches).

Checklist #

• To do: View caching, template compilation and the template cache are on in production (no warning on Setup > System information).
• To do: The team knows which cache to clear for which change, and uses --dry-run first.
• To do: Page caches are cleared after the code reload, not before (the deploy command does it).
• To do: The site is warmed after a full clear or a deploy.
• To do: Capacity is planned for signed-in traffic, which is rendered rather than served from the response cache.

Related pages #

• Static and response cache
• Peak traffic planning
• Performance and caching for websites
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.