PHP OPcache and Realpath Cache Tuning for WordPress on a VPS

Every PHP request compiles the requested script from source unless the compiled bytecode is already cached. A typical WordPress installation contains several hundred PHP files, and without OPcache, PHP re-parses and re-compiles them on every single request — a waste of CPU that shows up directly in TTFB and throughput. OPcache stores compiled bytecode in shared memory, and its smaller cousin, the realpath cache, avoids repeated filesystem stat() calls. This guide covers the settings that matter for WordPress on a VPS and how to verify they are working.

What OPcache does

OPcache is bundled with PHP and enabled by default in most distributions, but the defaults are conservative. Three settings control the essentials:

• opcache.memory_consumption — how much shared memory holds compiled scripts
• opcache.max_accelerated_files — how many distinct files can be cached
• opcache.validate_timestamps / opcache.revalidate_freq — how often PHP checks files for changes

Recommended OPcache settings for WordPress

Put these in php.ini (for PHP-FPM, that is usually /etc/php/8.x/fpm/php.ini):

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.enable_cli=1
opcache.interned_strings_buffer=16

• memory_consumption=128 — a full WordPress install with plugins and a theme typically uses 64–128 MB of bytecode cache; start at 128 and check usage
• max_accelerated_files=10000 — WordPress plus a plugin-heavy setup easily exceeds the default of 4000–10000; set it high enough that opcache_get_status() shows no “full” warnings
• revalidate_freq=60 — recheck files every 60 seconds so deploys show up quickly without a stat() call on every request
• enable_cli=1 — cache bytecode for WP-CLI and cron jobs too

Tuning the realpath cache

Every include or require triggers a filesystem lookup unless the resolved path is cached. The realpath cache stores those resolutions:

realpath_cache_size=4096k
realpath_cache_ttl=600

On a busy WordPress site with many plugins, the default 4 MB realpath cache can fill quickly. Raising it to 4096 KB (or more on larger setups) reduces stat() syscalls noticeably — a cheap win that costs almost no memory.

Where the settings go

For PHP-FPM, edit /etc/php/8.x/fpm/php.ini, then restart: systemctl restart php8.x-fpm. For Apache mod_php, edit the CLI and Apache php.ini files instead. Verify the settings loaded with php -i | grep opcache or check opcache_get_status() from a small PHP script.

Verifying the cache is working

Create a tiny script with phpinfo() or run this one-liner to inspect cache health:

php -r "var_export(opcache_get_status());"

Look at these fields:

• hits vs misses — hits should be in the high thousands of percent of misses after warm-up; if misses keep growing, the cache is too small
• memory_used vs memory_size — if used approaches the limit, raise memory_consumption
• num_cached_scripts vs max_cached_keys — if equal, raise max_accelerated_files

A healthy cache shows near-100% hit rates after the first few requests, which means PHP is serving precompiled bytecode instead of re-parsing source.

Checking OPcache from the WordPress admin

If you prefer a visual check, install a small plugin such as OPcache Manager or use a standalone status script placed outside the web root. Both read opcache_get_status() and render the same numbers — hits, misses, memory used, and cached scripts — in a readable dashboard. The key figures to watch:

• Hit rate: should settle above 95% after warm-up; below that, raise memory or file limits
• Memory used vs memory size: if the bar is nearly full, raise opcache.memory_consumption
• Cached scripts vs max cached keys: if they are equal, raise max_accelerated_files

Set up a weekly cron job that logs these numbers, so a plugin update that blows past the cache limits shows up in your monitoring before it slows the site down.

OPcache and PHP 8.x JIT

PHP 8.0 and later include a JIT compiler that can further speed up CPU-heavy PHP code. For WordPress, JIT rarely moves the needle because most of the work is I/O and database queries, not tight loops — and JIT consumes memory that could otherwise hold cached bytecode. A reasonable compromise is to leave JIT off for typical WordPress installs and enable it only if profiling shows genuine CPU-bound PHP work.

Common mistakes

• Setting memory_consumption too low: the cache fills, old scripts get evicted, and hit rate collapses
• Leaving validate_timestamps=0 in production with frequent deploys: stale bytecode can serve old code after updates
• Forgetting enable_cli=1: cron jobs and WP-CLI run uncached and slow down scheduled tasks
• Ignoring WooCommerce and plugin-heavy builds: they easily push file counts past 10,000, so re-check num_cached_scripts after adding plugins
• Not restarting PHP-FPM after changing php.ini: OPcache settings only load at startup

Putting it together

OPcache tuning is one of the highest-return changes you can make on a WordPress VPS: it reduces CPU usage, lowers TTFB, and often delays the need for a bigger plan. Pair it with page caching and a CDN for the full effect.

If your current VPS struggles with PHP workloads, see the full VPS comparison on our table to find a plan with more CPU headroom, and browse our provider breakdowns and buying guides on the main site for more WordPress and PHP performance guides.

Looking for a place to run these setups? InterServer VPS plans offer straightforward pricing with plenty of headroom, and Cloudways managed cloud hosting is a solid choice if you prefer a managed platform on top of fast infrastructure. (Disclosure: we may earn a commission if you sign up through these links, at no extra cost to you.)