OPcache
debt(d7/e3/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints list phpinfo, opcache-gui, and blackfire — these are specialist tools a developer must deliberately invoke. A disabled or misconfigured OPcache (e.g. validate_timestamps=1, low memory_consumption) produces no error or warning; the site works correctly but is silently slow, and the problem only surfaces when someone profiles or inspects phpinfo. It does not score d9 because the tools are readily available and the pattern (opcache.enable=0 in php.ini) is concrete.
Closest to 'simple parameterised fix' (e3). The quick_fix is a small set of php.ini directives: enable=1, memory_consumption=256, max_accelerated_files=20000, validate_timestamps=0. This is more than a single-line patch (multiple settings, plus a PHP-FPM restart and deployment procedure awareness) but well short of a multi-file refactor. Scores e3 rather than e1 because the common_mistakes reveal several interacting settings and an operational step (restart FPM) that must be coordinated.
Closest to 'persistent productivity tax' (b5). OPcache is a server-level configuration choice that applies to both web and CLI contexts across the entire PHP runtime. Misconfiguration (stale bytecode after deploys, eviction under memory pressure, timestamp validation in production) imposes an ongoing operational tax: every deployment must account for cache invalidation, memory sizing must be revisited as the codebase grows, and CLI scripts may behave differently if opcache.enable_cli is not set. It doesn't reach b7 because it doesn't shape code structure, only operational/deployment practice.
Closest to 'notable trap' (t5). The canonical misconception — that OPcache is only for high-traffic sites — is a documented gotcha that causes developers to leave it disabled in production. A second well-known trap is validate_timestamps=1 silently defeating the cache, and a third is forgetting to restart PHP-FPM after deploy so stale bytecode serves old code. These are all documented, eventually-learned gotchas rather than behaviour that contradicts similar concepts in other ecosystems, placing this squarely at t5.
Also Known As
TL;DR
Explanation
OPcache (bundled since PHP 5.5) stores compiled PHP bytecode in shared memory so subsequent requests skip the parse-and-compile phase. It can reduce CPU usage by 50–90% for busy applications. Key configuration settings include opcache.memory_consumption (typically 128–256 MB), opcache.max_accelerated_files (set above your file count), opcache.validate_timestamps (disable in production for maximum speed; invalidate cache on deploy), and opcache.jit_buffer_size (PHP 8.0+ JIT). Misconfigured OPcache can expose cached files to other processes — ensure opcache.restrict_api is set appropriately.
Common Misconception
Why It Matters
Common Mistakes
- Leaving OPcache disabled in production because it was absent from the default php.ini.
- Setting opcache.validate_timestamps=1 in production — defeats caching by checking file mtimes on every request.
- Forgetting to restart PHP-FPM after deploying — stale bytecode serves old code until the cache expires.
- Setting opcache.memory_consumption too low — cache eviction under memory pressure causes random misses.
Code Examples
; php.ini — OPcache not configured, effectively disabled
; opcache.enable=0; php.ini production settings
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0 ; clear cache on deploy instead