WordPress
Opcode cache
Also called OPcache.
Opcode cache is compiled PHP bytecode held in shared memory so the server does not read and parse every PHP file on every request. In PHP it is OPcache, which ships with the language.
How it is measured
Check status with opcache_get_status() or a phpinfo() page. The numbers that matter are memory used versus opcache.memory_consumption (default 128 MB), number of cached scripts versus opcache.max_accelerated_files (default 10,000), and the opcache_hit_rate. A hit rate near 100 percent after warm-up is normal.
A WordPress site with many plugins can exceed the default script limit. Setting opcache.validate_timestamps to 0 on production speeds file checks but means a deploy needs a reset or a PHP-FPM reload.
Worked example
A WooCommerce site with 38 plugins and a heavy theme has 14,200 PHP files. With max_accelerated_files at 10,000, opcache_get_status() shows num_cached_scripts stuck at 10,000 and an oom_restarts count of 6 in a week. TTFB varies between 220 ms and 900 ms.
Raising max_accelerated_files to 20,000 and memory to 192 MB stops the restarts. TTFB settles near 240 ms.
How it differs
An opcode cache saves the compile step of PHP code, while an object cache stores data your code computes at runtime. They sit at different layers and do not replace each other. The opcode cache lives inside PHP-FPM workers and is cleared when PHP restarts; an object cache is a separate service.
Common errors
Running with OPcache disabled in a Docker image. Leaving validate_timestamps on and wondering why disk reads are high. Turning it off during debugging and forgetting it. Deploying with validate_timestamps off and not resetting, so old code runs. Sharing the pool between many sites with an undersized memory limit.
In practice
Log in to your server or ask your host for the OPcache status. If num_cached_scripts hits the limit or memory is full, raise the values and restart PHP-FPM. Add an OPcache reset to your deploy step.