Caching — Cheat Sheet
Your site is fully cached out of the box — nothing to set up. This page is the quick primer: what the layers are, how to get them out of your way while you debug, how to clear or restart things, and how to check it's all working. Everything here links to the full story.
The four layers in 30 seconds
- Nginx front cache — whole pages served straight from the web server in ~10-second bursts; flattens traffic spikes. → Front cache & page cache
- Drupal's page cache — anonymous pages come ready-made from memory. → same page
- Redis/Valkey object cache — every cache bin (your custom bins too) lives in RAM, not the database. → The Redis/Valkey object cache
- PHP opcache — compiled code; why a deployed change takes about a minute to show up. → opcache & APCu
Debugging? Use a .dev. alias — caching gets out of the way
The single most useful move on this page. Add an alias with .dev. in the
name (say www.dev.example.com) and requests through it run in development
mode — the whole serving stack relaxes at once, far more than any single
cache switch: errors on screen instead of a white page, opcache re-checks
your code instantly, the front cache drops to 1 second, and the page-cache
and aggregation toggles BOA normally hardcodes are handed back to you. On
Drupal 8+ one optional drop-in file also routes the render caches to a null
backend. Real visitors on the real names notice nothing.
The .dev. view also unlocks BOA's X-Ini-* and X-Valkey-* debug
response headers. The X-Ini-* set makes reading your effective INI
configuration easy: each header shows an active value, and X-Ini-Loc-Src /
X-Ini-Plr-Src name the exact file that supplied it. These debug sets exist
only on .dev. names, never on your live URLs.
→ Full setup: The .dev. preview URL
One-off checks on any URL, no alias needed (humans only, single request):
?nocache=1— skip the front cache and Drupal's page cache once.?noredis=1— run once with the object cache off entirely — the with/without test the.dev.view doesn't cover.
Clearing caches
The panel's Flush all caches task does it with one click — see Site-health tasks. From your shell:
drush @example.com cc all # clear all Drupal caches (Drupal 6/7)
vdrush @example.com cr # same for Drupal 8+
Restart PHP gracefully (plan-gated)
The fix for stale-APCu symptoms after an update (an old plugin list, a config change that won't stick) — APCu can't be flushed remotely, so you recycle the PHP workers instead, without dropping a connection:
touch ~/static/control/run-php-fpm-reload.pid
The server's monitor picks the file up within moments, reloads every installed PHP version, and removes the file itself; a cooldown prevents storms. → When APCu goes stale
Force a Valkey restart (plan-gated)
For the rare day the object cache itself misbehaves — restart its server the
same self-service way (either name works, run-redis-restart.pid too):
touch ~/static/control/run-valkey-restart.pid
Your sites stay up throughout: they ride the automatic database fallback during the restart and recover on their own.
Both levers are plan-gated: if the file just sits there and nothing happens, the feature isn't enabled on your plan — open a support request and your host does it for you.
Is the fast cache actually working?
Set redis_debug_header = TRUE in your site's
INI control file, then:
curl -sI https://example.com/ | grep -i x-cache
X-Cache-State: up with X-Cache-Backend: redis (or chainedfast) is the
fast path; db or backoff means the site is on the database right now.
Turn the setting off when you're done. These X-Cache-* headers are the one
debug family that works on your live URLs — gated only by the INI setting,
by design, so you can check production without a .dev. alias.
→ All header values and what they mean: Confirming it's working
The three dials most people touch
| Setting | What it does | Default |
|---|---|---|
speed_booster_anon_cache_ttl |
Longer front-cache window for anonymous visitors | 10 |
redis_exclude_bins |
Keep named cache bins in the database instead | (none) |
redis_cache_disable |
Object cache off entirely — debugging only | FALSE |
They go in your site or platform INI control file — which file, and how. There are 18 caching dials in all, each documented next to the behaviour it changes on the caching pages, and catalogued in the variables reference.
If something's weird
- A "new" site shows another site's errors or content after a domain name was reused → stale cache leftovers; the fix and the naming habit that avoids it.
- Styling breaks after a cache clear (Drupal 6/7 with a raised TTL) → enable the bundled AdvAgg module; why this happens.
- Still stuck? Start at Something looks broken.
Going deeper
- The whole topic, in depth: Caching on your sites — routing and isolation, cache clearing internals, size limits, the automatic fallback, every setting.
- Server-side sizing and internals (for operators): Cache tuning · self-healing monitors.