Opcode Caching
debt(d5/e3/b5/t5)
Closest to 'specialist tool catches it' (d5). The detection_hints list opcache-gui, blackfire, and phpinfo — all specialist tools that require deliberate inspection. A disabled or misconfigured OPcache doesn't surface in application logs or cause visible errors; you must actively check phpinfo() output or use a profiling tool like Blackfire to notice the misconfiguration. Default linters won't flag php.ini settings, so d3 is too generous.
Closest to 'simple parameterised fix' (e3). The quick_fix is essentially a php.ini change (enable OPcache, set validate_timestamps=0, tune memory_consumption) plus a deploy hook or restart step. This is slightly more than a one-line patch (e1) because it may touch php.ini, deployment scripts, and require a PHP-FPM restart, but it doesn't span multiple files in application code — it's a localised configuration change.
Closest to 'persistent productivity tax' (b5). OPcache configuration applies across both web and CLI contexts and affects every deployment workflow (stale bytecode after deploy is a recurring operational concern). Every developer touching deployments must understand cache invalidation. However, it doesn't reshape application architecture — it's an infrastructure-level setting — so b7 is too strong. It imposes an ongoing operational tax on every deployment and environment setup.
Closest to 'notable trap' (t5). The misconception field documents a well-known gotcha: developers assume OPcache only matters for high-traffic sites and skip enabling it. Additionally, validate_timestamps=1 silently halves the benefit, and stale bytecode after deployment serves wrong code — all documented gotchas that most PHP developers eventually learn the hard way. These are non-obvious but documented in PHP community resources, fitting t5.
Also Known As
TL;DR
Explanation
PHP normally parses and compiles source files on every request. Opcode caching (via OPcache, the standard built-in extension since PHP 5.5) stores the compiled bytecode in shared memory so subsequent requests for the same file skip compilation entirely. This can improve throughput by 50–90% for typical applications. The JIT compiler introduced in PHP 8.0 extends this further by compiling hot bytecode to native machine code. Proper OPcache configuration (adequate memory, file count, and deployment cache-clear strategy) is essential in production.
Common Misconception
Why It Matters
Common Mistakes
- Not enabling OPcache in production — it is often off by default in minimal PHP installs.
- Setting opcache.validate_timestamps=1 in production — checks file mtimes on every request, negating half the benefit.
- Not setting opcache.memory_consumption large enough — cache evictions cause repeated recompilation.
- Deploying new code without restarting PHP-FPM or touching opcache.php — stale bytecode serves old code.
Code Examples
; php.ini — OPcache disabled or misconfigured:
;opcache.enable=1 ; Commented out — no caching
opcache.memory_consumption=64 ; Too small for large frameworks — use 256+
opcache.validate_timestamps=1 ; File stat on every request in production — set to 0; php.ini — OPcache production settings
opcache.enable=1
opcache.memory_consumption=256 ; MB — size to your codebase
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0 ; disable in production — manual invalidation
opcache.revalidate_freq=0
opcache.save_comments=1 ; needed for PHPDoc-based tools
; After deploy — invalidate stale cache
; opcache_reset(); or restart PHP-FPM
php -r 'opcache_reset();'
; Or per file: opcache_invalidate('/var/www/app/bootstrap.php', true);