Which cache backend makes sense for Doctrine ORM on a low-traffic PHP app: APCu or Redis?
0 reputation · 04 Oct 2022, 00:46 UTC
I'm running a small, low-traffic PHP application on Doctrine ORM (2.x/3.x line) and want to cut database and CPU costs. I've already set associations to lazy fetch and pre-generated proxies with auto_generate_proxy_classes disabled in production, which removed most of the obvious overhead.
The remaining decision is the metadata and query cache backend. The documentation supports adapters such as APCu and Redis, but the trade-offs for a tiny workload aren't clear to me. APCu is per-process, so with several PHP-FPM workers each worker keeps its own cache, affecting hit rates and invalidation. Redis is shared and consistent across workers, but adds an extra service to deploy, secure, and monitor — which itself has a cost that may exceed what a low-traffic app saves.
I also want to avoid making things worse: I've read that lazy loading can produce N+1 query patterns if associations are touched inside loops, so I plan to verify query counts with the SQL logger in staging before and after any change.
For a workload with only a handful of requests per minute:
- Is a shared Redis cache measurably better than per-process APCu at this scale, or is the operational overhead rarely justified?
- Which cache (query, result, metadata) gives the biggest cost reduction for infrequent requests?
- What metric best confirms the choice — cache hit rate, query count per request, or response time?