Drupal Core Caching ↔ Varnish Reverse Proxy: When Is the First Miss the Bottleneck?

Short answer

On a cache miss, the bottleneck is almost always Drupal, not Varnish. A miss forces a full Drupal bootstrap — PHP execution, module loading, database queries — while Varnish contributes only a hash lookup and a backend connection, typically single-digit milliseconds. The practical question is not whether the first miss is expensive (it is, by design) but how to measure the split precisely and how to keep the warm-cache hit rate high enough that misses are rare.

Separating likely explanation from confirmed fact

Confirmed behavior (Drupal 9/10, well established): Drupal emits cacheability metadata — Cache-Control, X-Drupal-Cache-Tags, and cache contexts — on cacheable responses. Varnish can honor Cache-Control: max-age directly and can be configured to ban on tag-like surrogate keys. Drupal core does not itself send PURGE/BAN requests to Varnish when cache tags are invalidated; that gap is real and is the source of your unresolved decision.

Likely explanation, not confirmed for your site: that PHP bootstrap dominates miss latency. This is true in the general case, but your actual split depends on modules, database latency, and whether the miss also misses the Dynamic Page Cache and render cache. Measure before tuning.

Measurement strategy

Avoid XHProf/Xdebug for the baseline — their overhead inflates bootstrap time. Instead:

1. Log Varnish-side timing with varnishlog, watching BereqHeader/BerespBody timestamps (or Timestamp records) for a forced miss. The backend fetch duration approximates Drupal's total response generation time.
2. Compare against Drupal's own view: enable the X-Drupal-Cache / X-Generator headers and use the web server's request-time log or a simple curl -w timing against the origin directly, bypassing Varnish.
3. Run a load tool (wrk, ab) twice against the same URL: once through Varnish, once directly against the web server. The delta on a cold cache isolates Varnish's per-request overhead; the absolute origin number is your bootstrap-plus-render cost.
4. Repeat under realistic concurrency — a single cold miss and a stampedes-under-load miss behave differently, and high traffic is where the first miss actually hurts.

Confirming cache-tag-driven purges

Drupal core does not push invalidations to Varnish. To make tag-based purging work at all you need a contrib module (the Purge module suite with a Varnish purger is the standard approach) plus VCL that accepts BAN requests and matches against the tag header Drupal sends. Verify end to end:

1. Check responses carry the tag header: curl -sI https://example.com/node/1 | grep -i -E 'cache-tags|surrogate'.
2. Edit the content so Drupal invalidates the tag, then inspect varnishlog for an incoming BAN and a matching ban hit on the cached object.
3. Re-request the URL and confirm X-Varnish/Age shows a fresh fetch, not a stale hit.

If no BAN arrives in the log, the problem is on the Drupal/purger side; if the BAN arrives but nothing is evicted, the VCL ban expression doesn't match the header format.

Automatic invalidation or manual purges?

For most sites: automatic, tag-based invalidation via the Purge module, with manual varnishadm ban kept as an operational fallback. Manual-only purging doesn't scale with editorial activity and guarantees stale content between purges; relying on max-age alone trades correctness for simplicity. The caveat: tag-based bans in Varnish can accumulate and slow lookups if bans are never garbage-collected, so use ban-lurker-friendly VCL (ban on obj.http rather than req.http) and monitor ban list length.

One missing detail changes this recommendation: your Varnish version. Ban behavior and VCL syntax differ meaningfully between Varnish 6.x and 7.x, and the purger configuration must match — confirm which you run before writing the VCL.