Cache warming after changes #

This page is for operations teams in public bodies who clear caches after a deploy, a restore or an urgent correction, and who do not want the first visitors (or a surge after a press release) to meet a slow site. It answers how to warm the caches again with the tools Exponential provides. The references are Preloading caches, Operating a site and the hosting page Cache clearing and warming.

Contents #

1. Why warm
2. The tools
3. Warming after a deploy
4. Warming before an announcement
5. Checklist

Why warm #

"After a clear or a deploy the first visitor pays for the render" (Operating a site). Rendered pages are fast once they are cached; the first request of each page after a clear is the slow one. On a public-sector site a clear is often followed by a peak: a deploy in the evening, then everyone opens the site in the morning; or a correction published right before a press release.

The tools #

Use the name of your own public siteaccess for --siteaccess. Details: Preloading caches and Preload Sites view.

Warming after a deploy #

exp:velocity deploy clears the caches that hold finished pages last, after the new code runs, and then requests the warm-up URLs so the first visitor finds the caches built (Deploying). Put your most visited pages into the list:

./console exp:velocity config get DeploySettings WarmUpURL --allow-root-user

After a restore, or when you cleared everything by hand, run a preload:

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

To keep every published page warm, a cron line such as the one in the guide:

php bin/php/warm.php --allow-root-user >> var/log/cache-warm.log 2>&1

With several web servers, warm each node; their caches in front of PHP are local.

Warming before an announcement #

When communications plans a release that will bring many visitors to a few pages:

1. Publish the pages early enough for the caches to expire and refill, or clear only what changed.
2. Request the announced pages and their parents once, for example with the Preload Sites view limited to a small depth.
3. Check that the pages are served from the cache (curl -sI shows X-Cache under Velocity).
4. Avoid deploys and full cache clears in the hours before the announcement; book them in a change freeze.

Checklist #

• To do: WarmUpURL[] lists your most visited pages.
• To do: Runbooks for restores and full clears include a preload.
• To do: Each node is warmed when there are several.
• To do: Announcements are coordinated with operations, with no full clear just before them.

Related pages #

• Availability index of this folder
• Velocity response cache and HTTP cache
• Capacity planning
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.