Memory‑vs‑Disk Trade‑Off: LiipImagine Bundle Cache Backend for Sulu Asset Management

Answer the exact question first

For a typical Sulu deployment using LiipImagineBundle:

1. Memory footprint of the in‑memory array cache – cannot be given as a fixed number; it scales with the count of distinct filter variants per asset, the average size of the transformed binary data stored (if the backend stores full images), and the number of PHP worker processes. In practice, a modest catalog of a few hundred assets with 3‑4 variants each may consume tens of megabytes per worker, while larger catalogs can exceed available RAM in constrained containers.
2. File‑based cache response time under concurrency – on a cache hit, latency is similar to the array cache because the file is read from the OS page cache; on a miss, extra disk I/O (write then read) adds a few milliseconds per request. Under high concurrent resize loads, the file‑based cache avoids per‑worker memory duplication, so aggregate RAM pressure is lower, but total latency may rise slightly if the storage subsystem is slow.
3. Cache invalidation when an asset is updated – Sulu does not rely solely on TTL. Asset update events trigger a listener that calls the LiipImagineBundle cache manager to remove the affected variant keys. The exact behavior depends on the Sulu version and whether the listener is enabled; if the listener is missing or misconfigured, fallback to TTL occurs.

Confirmed facts

• LiipImagineBundle provides both "array" (in‑memory per PHP process) and "filesystem" cache backends; Sulu’s asset controller injects the cache service configured via Symfony’s cache pool.
• The array cache is not shared across containers or PHP‑FPM workers, leading to duplicated storage in horizontally scaled setups.
• Sulu’s AssetBundle includes an event listener for "asset.updated" that, when active, calls ImagineCache::remove for the asset’s filter variants.

Likely explanation / recommendation

If your container enforces a strict RAM ceiling (e.g., < 500 MiB per pod) and you expect more than a few hundred distinct image variants, start with the filesystem cache to keep memory usage predictable. Monitor worker RSS and cache hit ratio; only switch to the array cache if you measure that the extra latency from disk I/O is unacceptable and you have sufficient headroom for per‑worker memory duplication.

Steps to validate the choice for your environment

1. Identify the active cache pool: php bin/console debug:container --parameter liip_imagine.cache.callable (or inspect config/packages/liip_imagine.yaml).
2. In a staging clone, enable Symfony’s cache profiler or symfony console cache:pool:stats to record hit/miss ratios and average get/set times for both backends.
3. Record PHP worker RSS before and after a warm‑up run that generates all needed variants (e.g., ps -o rss,pid -C php-fpm).
4. If RSS approaches your container limit, prefer the filesystem cache; otherwise, the array cache may be viable.

Missing diagnostic detail that would change the recommendation: Please provide the average number of distinct filter variants per asset and the typical size of the original assets (or the average transformed binary size). This lets us estimate the per‑worker memory footprint of the array cache and decide whether it fits within your RAM budget.