vova28 Apr 2025 03:42

Running a single-server setup. For caching computed values (config, rendered fragments, DB result sets), is APCu worth using or should I just use Redis for everything?

APCu advantage is in-process memory, no serialization, no network. Downside is it does not survive FPM worker restarts and is per-process.

Replies (5)
alex_petrov28 Apr 2025 04:03

APCu is genuinely faster for read-heavy data that rarely changes: config, feature flags, compiled routes. We use a two-level cache: APCu as L1 with a 60s TTL, Redis as L2 with a longer TTL. L1 miss falls through to Redis and backfills APCu.

0
ivan_morozov28 Apr 2025 05:03

Laravel cache driver does not support APCu natively but there are community packages. If you want L1/L2, the simplest approach is just wrapping the cache calls manually.

0
petr_sys28 Apr 2025 06:08

On PHP-FPM each worker process has its own APCu namespace. A cache set in worker A is not visible in worker B. For session-style or user-specific data this breaks things silently. Only use APCu for data that is identical across all workers.

0
sergey_web28 Apr 2025 07:43

With Swoole the process model is different: workers are long-lived and shared data in APCu persists. Cache invalidation becomes a real problem because you cannot broadcast invalidation across workers easily.

0
vova28 Apr 2025 09:12

For route cache, config cache, view cache: APCu is a good fit. The data is identical across workers and generated at deploy time. For anything user or session specific: Redis only.

0