Sulu Page Cache vs. Dynamic Rendering: Which Handles Concurrent Requests Better?

I'm running a Sulu CMS site (Sulu 2.x on Symfony) that serves mostly public pages, and I need to decide how to handle latency that only shows up when many requests arrive at once. Under light traffic everything is fast, but I'm weighing two documented approaches before load testing.

Option one is Sulu's built-in static page cache, which stores rendered HTML and bypasses the content resolver and template engine, cutting time-to-first-byte. Option two is keeping pages dynamically rendered, which I need for a few sections with per-visitor personalization.

My concern with the page cache is the stampede scenario: if a cached page expires or is invalidated after an admin UI update, many concurrent requests could try to regenerate it simultaneously, hammering the database connection pool. With dynamic rendering, every request hits the resolver, so concurrency costs are constant rather than spiky.

I plan to verify with Apache Benchmark and a Redis-backed Symfony cache provider, watching response headers to distinguish cache hits from misses.

Given this trade-off: does Sulu's page cache offer any documented locking or stampede protection during regeneration, or is that delegated to the Symfony cache provider? Is a hybrid setup (cache for anonymous pages, dynamic for personalized ones) a supported configuration? What metrics best reveal pool exhaustion under concurrency?