Filesystem full-page cache disk growth on low-traffic Magento storefronts

Assessment

The default filesystem full‑page cache remains cost‑effective for a low‑traffic Magento Open Source 2.4.x storefront, provided the cache size stays modest and cron:clean runs regularly; Redis or Varnish only become cheaper when traffic or storage constraints make the fixed costs of those back‑ends worthwhile.

Confirmed facts

• Default FPC writes to var/page_cache; disk usage grows with the number of unique pages cached.
• Cache entries expire only after the TTL; cron:clean removes stale entries, but its frequency controls accumulation.
• Redis FPC uses memory with a TTL; a small dedicated instance costs a fixed amount that may outweigh disk‑space savings on < 100 requests/hour traffic.
• Varnish reduces FPC load but adds a separate reverse‑proxy layer, increasing operational overhead and fixed costs.
• Reducing cron:clean from every 5 minutes to once daily is safe for very low traffic, yet may delay stale‑page removal and cause occasional size spikes.

Likely explanation

For a storefront that serves only a few hundred page views per day, the default filesystem cache remains cost‑effective because the absolute disk consumption stays modest and the extra memory cost of Redis or the operational overhead of Varnish rarely justifies the switch. The decisive factor is the ratio of cache size to available storage and the marginal cost of additional memory versus the saved disk I/O, which is negligible at low request rates.

Steps needed

1. Measure current cache size: run du -sh var/page_cache and count files older than the TTL with find var/page_cache -type f -mtime +1 | wc -l.
2. Check cron schedule: grep cache:clean /etc/cron.d/* to see how often the cleanup job runs.
3. If size exceeds the storage budget or grows beyond predictable limits, consider adjusting cron frequency or increasing disk space before evaluating alternative back‑ends.
4. When traffic consistently stays below a few hundred requests per hour, a Redis instance larger than the current disk usage will usually increase total cost, so the filesystem cache is preferred unless storage constraints arise.

Please provide the current size of var/page_cache and the age of its oldest entries; this information will determine whether a larger single instance or a dedicated cache backend offers a better cost balance.