How to enable and configure OPcache for faster PHP

1. What OPcache does
2. Check whether OPcache is enabled
3. Enable OPcache in php.ini
4. Key production settings
5. Development settings
6. Important: reset OPcache on every deploy
7. Restart PHP-FPM to apply changes
8. JIT on PHP 8
9. Conclusion

OPcache is one of the biggest speedups available to a PHP app, and it costs you almost nothing to turn on. Every time PHP runs a script it normally reads the file, parses it, and compiles it to bytecode before executing. OPcache stores that compiled bytecode in shared memory, so subsequent requests skip the parse-and-compile step entirely. On a typical Laravel or WordPress app that alone can cut response times by a large margin.

#What OPcache does

PHP is interpreted, but it doesn't run your source directly. It compiles each .php file into intermediate bytecode (opcodes) and then executes that. Without a cache, this compilation happens on every single request, for every file the request touches.

OPcache caches the compiled opcodes in shared memory the first time a file runs. After that, PHP fetches the bytecode straight from memory and goes directly to execution. The parsing and compilation overhead disappears, which is why enabling OPcache is usually the first PHP performance change worth making.

#Check whether OPcache is enabled

OPcache ships with PHP and is often already installed, just not configured well. Check from the CLI:

php -i | grep opcache.enable

A clearer view comes from opcache_get_status(), which reports live memory usage and hit rate. Note this reflects the CLI SAPI when run from the command line; for FPM, expose it through a web script:

<?php
var_dump(opcache_get_status());

Look at opcache_enabled, memory_usage, and opcache_statistics.opcache_hit_rate. A healthy production server sits well above 95% hits.

#Enable OPcache in php.ini

If it isn't on, enable it in your php.ini. On Ubuntu the FPM config usually lives at /etc/php/8.3/fpm/php.ini (adjust the version):

opcache.enable=1
opcache.enable_cli=0

Leave opcache.enable_cli off unless you specifically run long-lived CLI workers; for normal artisan and composer commands it just wastes memory caching one-off scripts.

#Key production settings

The defaults are conservative. These four settings matter most:

; Shared memory for compiled bytecode, in MB
opcache.memory_consumption=256

; Memory for interned (deduplicated) strings, in MB
opcache.interned_strings_buffer=16

; Max number of files OPcache will cache; set above your file count
opcache.max_accelerated_files=20000

; Don't check the filesystem for changes on every request (production)
opcache.validate_timestamps=0

• opcache.memory_consumption — total shared memory for cached bytecode. 128–256 MB is comfortable for most apps; if it fills up, OPcache starts evicting and your hit rate drops.
• opcache.interned_strings_buffer — PHP stores each unique string once. Large frameworks use a lot, so 16 MB is a sensible bump from the default 8.
• opcache.max_accelerated_files — the cap on cached files. Count your files with find . -type f -name '*.php' | wc -l and set this comfortably higher. OPcache rounds up to the next prime.
• opcache.validate_timestamps — when 0, OPcache never checks if a file changed on disk, which is fastest and correct for production. The trade-off is covered below.

#Development settings

In development you want changes to show up without a restart. Keep timestamp validation on and check periodically instead of on every request:

opcache.validate_timestamps=1
opcache.revalidate_freq=2

opcache.revalidate_freq=2 means OPcache re-checks a file's mtime at most every 2 seconds, a good balance between freshness and overhead during local work.

#Important: reset OPcache on every deploy

With opcache.validate_timestamps=0, OPcache will happily serve the old bytecode forever, even after you deploy new code, because it never looks at the files again. You must explicitly clear the cache as part of your deploy.

The cleanest option is to reload PHP-FPM, which drops the cache:

sudo systemctl reload php8.3-fpm

If you'd rather not reload the service, call opcache_reset() from a web request (it has no effect from CLI when FPM holds the cache), or use a tool like cachetool:

cachetool opcache:reset --fcgi=/run/php/php8.3-fpm.sock

Skipping this step is the single most common OPcache mistake: a deploy "doesn't take" because the server is still running cached bytecode.

#Restart PHP-FPM to apply changes

Editing php.ini doesn't do anything until PHP-FPM reloads it:

sudo systemctl reload php8.3-fpm
# verify the new settings
php-fpm8.3 -i | grep opcache.memory_consumption

#JIT on PHP 8

PHP 8 added a JIT compiler that lives inside OPcache and can compile hot paths to native machine code. It helps CPU-bound workloads more than typical web requests, and it has its own configuration. See enabling the PHP 8 OPcache JIT for the details rather than turning it on blindly here.

#Conclusion

Enabling OPcache is the highest-leverage, lowest-effort PHP performance change you can make: turn it on, give it enough memory, set validate_timestamps=0 in production, and remember to reset it on every deploy. From there, look at broader PHP performance tuning and, on Laravel, Laravel-specific optimizations to keep squeezing out latency.