Since PHP 5.5 the Opcache extension is part of the core and adds support for byte-code caching of PHP scripts. For a dynamic language such as PHP, a byte-code cache can increase the performance significantly, because it guarantees a script is compiled only once.
The default settings of the Opcache extension already boost PHP performance by a large amount, but you can tinker with the configuration settings to get even more out of it.
A Word of Warning: This post repeatedly mentions monitoring stats with
opcache_get_status(false). Because Opcache uses a unique pool of shared
memory for every SAPI, you cannot access the webservers statistics from the
console. The call has to be made through Apache or PHP-FPM.
Avoid Destructive Caching Behavior When Memory is Too Small
Opcache uses 64 MB of RAM to save the compiled PHP scripts by default and up to 3907 php scripts. This sounds more than enough to store your PHP application scripts, but there are caveats:
If your application uses code-generation or a PHP file based cache such as Symfony, Doctrine Annotations or FLOW3, then there might be a large amount of scripts that are not part of your source control.
If you do validate timestamps and your code changes in production, then the old cache entries are marked as "waste". This waste adds to the memory consumption of Opcache.
If you use the "new checkout for every release" deployment strategy, then Opcache might cache the same script multiple times in different filesystem locations. This can crowd out the available memory fast.
When Opcache is "full" under some circumstances it will wipe all cache entries and start over from an empty cache. When this happens and your server gets large amounts of traffic, this can cause a thundering herd problem or cache slam: lots of requests simoultaneously generating the same cache entries.
You absolutely want to avoid Opcache to restart with an empty cache.
The algorithm that detects whether opcache is "full" is depends on an unintuitive interaction between three different INI settings and is currently not documented. It helped to dig through the C code to understand it.
The three relevant ini variables are defined as follows:
opcache.memory_consumptiondefaults to 64 (MB) for caching all compiled scripts.
opcache.max_accelerated_filesdefaults to 2000 cacheable files, but internally this is increased to a higher prime number for undocumented reasons. The maximum is 100.000
opcache.max_wasted_percentageis the percentage of wasted space in Opcache that is necessary to trigger a restart (default 5).
Opcache works on a first-come, first-serve basis for the cache and does not use an eviction strategy such as Least Recently Used (LRU).
Whenever maximum memory consumption or maximum accelerated files is reached Opcache attempts to restart the cache. However if the wasted memory inside opcache does not exceed the max_wasted_percentage, opcache will not restart and every uncached script will be re-compiled every request as if there was no opcache extension available.
This means you absolutely want to avoid Opcache to be full.
To find the right configuration you should monitor the output of
opcache_get_status(false) which you can use to check for the memory, waste
and number of used cache keys:
cache_fullis true and a restart is neither pending nor in progress, that probably means that the waste is not high enough to exceed the max waste percentage.
You can check by comparing
current_wasted_percentagewith the INI variable
opcache.max_wasted_percentage. In this case also the cache hit rate
opcache_hit_ratewill drop below >=99%.
cache_fullis true and
max_cached_keysthen you have too many files. When there is not enough waste, no restart will be triggered. As a result there are scripts that don't get cached, even though there might be memory available.
If your cache is never full, but you are still seeing a lot of restarts, that can happen when you have too much waste or configured the max waste percentage too low.
To look for inefficient restart behavior you can evaluate the
opcache.memory_consumption setting) and
opcache.max_accelerated_files). Make sure to check when the last restart
To find a good value for
opcache.max_accelerated_files you can use this Bash
one-liner to get the number of PHP files in your project:
$ find project/ -iname *.php|wc -l 9607
Make sure to account for code-generated and cache files or multiple applications running inside the same FPM worker pool.
Avoid Unnecessary Filesystem Calls By Disabling Timestamp Validation
With the default settings, whenever a PHP file is executed (for example through
require) Opcache checks the last time it was modified on disk.
Then it compares this time with the last time it cached the compilation of that
script. When the file was modified after being cached, the compile cache for
the script will be regenerated.
This validation is not necessary in production, when you know the files never change. To disable timestamp validation add the following line to your php.ini:
With this configuration you have to make sure that during a deployment, all the caches get invalidated. There are several ways to ensure this happens:
Restart PHP FPM or Apache - The sledgehammer method of invalidating files in Opcache has the downside that it might lead to aborted requests and a very small amount of time where requests get lost.
opcache_reset(), which is tricky because it has to be called in a script executed by Apache or PHP-FPM to affect the webservers Opcache. You can add a special endpoint to your application and secure it using a secret hash.
Changing the document root and reloading the Nginx webserver configuration. Nginx completes all the currently running requests and starts new workers in parallel that serve requests with the new configuration.
For Apache, Rasmus has a blog post detailing their approach at Etsy.
Careful with the last two approaches, with them available Opcache memory is "full" very fast. See the previous section for more information on how memory configuration works.
For both cases you might need a maintenance script that calls
opcache_invalidate($file, true) on all scripts in old deployments or
opcache_reset() directly. Otherwise old deployments crowd out the cache for
new ones and you might end up with a full cache and an unaccelerated
3. Fast Shutdown
WARNING: Changing this option is known to cause segfaults under yet to be determined conditions. See the issue #146 on the Opcache repository for more information. We have therefore removed this as a hint.
Opcache can hook into the request shutdown and employ a different mechanism to shutdown
allocated memory using
This is supposedly faster, but neither the documentation nor the C code allow
me to make a good judgment about this claim. This just means that you should test
the impact of this change on your application yourself.
Putting Everything Together
If you combine all the results you get the following php.ini configuration for opcache in production:
opcache.memory_consumption=128 # MB, adjust to your needs opcache.max_accelerated_files=10000 # Adjust to your needs opcache.max_wasted_percentage=10 # Adjust to your needs opcache.validate_timestamps=0
We tested this on the Tideways demo application server, which was running with a "full" opcache because of the many different PHP applications running inside PHP-FPM there. The Symfony Sylius demo application showed the following considerable improvements, because now all scripts fit into opcache. Register for the Tideways demo to directly view this event yourself.
We also tested the Opcache configuration on the Profiler itself. In this case the cache was not already full, but timestamp validation was enabled.
With 180.000 requests compared before and after the release we can be very certain that the improvement of roughly 2ms can be attributed to the disabled timestamp validation.
Even though Opcache already provides a signifcant boost in PHP performance, you can still improve on it. This blog post expands on the small information available in the php documentation on opcache_get_status and the opcache configuration.