Full Page Cache or Varnish: Trade‑off for Concurrent Request Latency

Question

Goal: lower average and 95th‑percentile response time when Magento serves many simultaneous storefront requests.

Constraint: the solution must keep dynamic blocks such as the mini‑cart, login status, and personalized recommendations up‑to‑date without serving stale content.

Uncertainty: Full Page Cache relies on backend storage and can miss when URL variations or session‑dependent blocks differ, while Varnish offloads caching to the HTTP layer but requires accurate ESI tags and purge rules to avoid stale personalized data.

Which approach yields lower latency under a steady load of 200 concurrent users while preserving cart accuracy? What are the operational trade‑offs in managing FPC filesystem/Redis storage versus Varnish ESI configuration and purge complexity? How does each method affect cache hit ratio for personalized pages when TTL values are adjusted?

Tasadduq Burney · Answer

Answer
Under a steady load of 200 concurrent storefront users, Varnish with ESI typically delivers lower average and 95th‑percentile response times than Magento’s built‑in Full Page Cache (FPC). The memory‑based cache removes PHP‑FPM and database overhead for the bulk of the page, leaving only the hole‑punched dynamic blocks to hit the backend.
Why Varnish Wins

Full HTML is served from RAM in <1 ms.
Only ESI fragments (mini‑cart, login, recommendations) trigger a lightweight backend call.
CPU and I/O contention on the application server is reduced, improving scalability.

Operational Trade‑offs
Magento FPC (Filesystem or Redis)

Runs inside the Magento process; no separate server.
Requires cache backend configuration (filesystem can bottleneck on slow disks; Redis adds a network hop).
Cache clean‑ups and size monitoring are handled by Magento’s cron or admin UI.

Varnish + ESI

Separate Varnish server and VCL scripting.
ESI tags must be correctly placed; missing tags can serve stale cart data.
Purge rules (e.g., Magento’s Varnish purge API) must be wired to cart, login, and recommendation events.
Operational overhead: maintain Varnish, monitor hit ratios, and manage purge latency.

Cache Hit Ratio & TTL Sensitivity

Varnish’s hit ratio for personalized pages drops sharply when the TTL is long (e.g., 1 h) because the static cache is served regardless of customer context. Shorter TTLs or frequent purges are required to keep cart accuracy.
FPC’s hit ratio is less sensitive to TTL because dynamic blocks are always re‑fetched, but a long TTL can still serve stale static content (e.g., promotional banners) unless those are also hole‑punched.
Adjusting TTL: Varnish benefits from a 5–10 min TTL for personalized sections; FPC can safely use 30 min–1 h for static content with AJAX‑loaded dynamic blocks.

Next Steps
To confirm the recommendation for your environment, measure the average backend response time for an uncached personalized page (including all dynamic blocks). If that time exceeds ~80 ms, Varnish is likely the better choice; if it is lower, FPC may suffice and avoid extra operational complexity.
Once you have that metric, you can fine‑tune TTLs and purge rules to balance latency and freshness.

Full Page Cache or Varnish: Trade‑off for Concurrent Request Latency

1 answer

Answer

Why Varnish Wins

Operational Trade‑offs

Magento FPC (Filesystem or Redis)

Varnish + ESI

Cache Hit Ratio & TTL Sensitivity

Next Steps

Your perspective belongs here.

0 question comments