ProCache vs. $cache API for Handling Concurrent‑Request Latency in ProcessWire

Answer the Question First

For a page that starts out uncached, ProCache will give the lowest average latency under 50 concurrent requests. The static file is served directly by the web server, bypassing PHP and the database entirely. When the same page is requested again, the hit is almost instantaneous. The $cache API, while still faster than a full PHP/DB round‑trip, requires PHP to load the cache entry, merge it into the page, and then output HTML, so its per‑request cost is higher.

At 200 concurrent users the pattern holds: ProCache’s disk I/O is negligible because the web server reads a pre‑written file; the $cache API’s hit‑rate may drop if many keys are evicted from Redis or the file system, and each hit still incurs a PHP lookup.

Why ProCache Beats Fragment Caching in This Scenario

• Zero PHP execution on a hit – only the web server serves the file.
• Minimal disk I/O – the file already exists; no file‑system lock contention.
• Automatic TTL/clear rules keep the file fresh for most content types.
• No manual key management or invalidation logic.

The $cache API gives you granular control over fragments, which is valuable when pages contain user‑specific data or when only part of a page is expensive to render. However, each cached fragment adds a separate file or Redis key, and you must explicitly invalidate or expire each one on data changes.

Effort Comparison: Keeping ProCache Fresh vs. Managing $cache Entries

Aspect	ProCache	$cache API
Setup	Install module, enable, set TTL (usually 1–24h).	Write $cache->save() for each expensive fragment.
Invalidation	Module hooks clear pages on publish/expire; may miss API‑driven updates.	Call $cache->delete() or set expiration per key.
Maintenance	Watch for stale content; add custom hooks if needed.	Maintain key naming; monitor hit/miss stats.
Scalability (200 users)	Static files served by web server; negligible CPU.	Redis or file cache may grow; PHP still runs for each hit.

Impact on Disk I/O and Redis Memory at Scale

• ProCache – writes one static file per page. Subsequent reads are simple file reads; no Redis usage. Disk I/O spikes only on cache misses.
• $cache API – each fragment creates a separate file or Redis key. With many fragments, disk I/O for writes increases, and Redis memory consumption grows linearly with the number of cached items.

Practical Verification Steps

1. Enable ProCache and confirm static files appear in site/assets/cache/ProCache/.
2. Measure baseline latency with wrk or ab for 50 concurrent users.
3. Enable $cache fragment caching for a known expensive query.
4. Re‑run the load test and compare average latency and hit ratio.
5. Check response headers (e.g., X-ProCache-Hit) to confirm static file usage.
6. Verify Redis memory usage (redis-cli INFO memory) when fragment cache is populated.

Missing Diagnostic Detail That Could Flip the Recommendation

What percentage of your pages are fully static or cacheable versus containing dynamic user‑specific fragments? If most content is dynamic, ProCache’s benefit shrinks, and a mixed strategy (ProCache for static sections + $cache for fragments) may be optimal.

Conclusion

For a page that is initially uncached and under sustained concurrent load, ProCache delivers lower average latency and simpler maintenance. The $cache API shines when you need fine‑grained control over fragments, but it adds cache‑management overhead and higher per‑request CPU cost. Scaling to 200 users amplifies these differences: ProCache remains lightweight, whereas $cache can bloat Redis and increase disk I/O.