If you manage WordPress sites on a DirectAdmin server, DirectAdmin OPcache configuration is one of the highest-impact performance changes you can make — often cutting page generation time by 30–70% without touching a single line of application code. The challenge is that most guides stop at installation, leaving you with default settings that underperform on shared servers and custom settings that silently get wiped every time CustomBuild runs a rebuild. This guide covers every step: installation, memory sizing for 10–50 WordPress sites, and a reliable method to make your configuration survive rebuilds.
What Is PHP OPcache and Why It Matters for WordPress Performance
PHP is an interpreted language. Without a bytecode cache, every HTTP request forces the server to read each PHP file from disk, parse it into tokens, compile those tokens into opcodes, and then execute those opcodes. For a typical WordPress page load, that process repeats across hundreds of files — WordPress core, plugins, themes, and autoloaders — on every single request.
OPcache eliminates the read-parse-compile cycle by storing precompiled bytecode in shared memory. On subsequent requests, PHP skips directly to execution. The practical outcome on a WordPress site is significant:
- Server response time (TTFB) drops because PHP work per request shrinks dramatically.
- CPU usage falls, freeing resources for concurrent requests rather than burning cycles recompiling the same files.
- MySQL query load often decreases as faster PHP execution means less time holding database connections open.
- Hosting capacity increases — a server that previously handled 50 concurrent visitors can handle significantly more with OPcache active.
OPcache ships bundled with PHP 5.5+ and is the recommended bytecode cache for WordPress by both the WordPress.org hosting team and major managed hosts. Enabling and correctly sizing it is foundational to any DirectAdmin PHP performance optimization strategy.
Prerequisites and Compatibility Check
- PHP version: 7.4, 8.0, 8.1, 8.2, or 8.3 — all include OPcache.
- DirectAdmin with CustomBuild 2.0: Run
cd /usr/local/directadmin/custombuild && ./build versionto confirm. - Root SSH access: All steps require root or sudo privileges.
- Available RAM: At least 128 MB free beyond existing usage. Run
free -hto check.
Check whether OPcache is already loaded:
php -r "echo opcache_get_status() ? 'OPcache active' : 'OPcache not active';"
If you get a fatal error about an undefined function, OPcache is not compiled in — proceed to Step 1. If it returns OPcache active, skip to Step 2 to tune the settings.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Step 1: Install OPcache via DirectAdmin CustomBuild 2.0
grep opcache /usr/local/directadmin/custombuild/options.conf
You should see opcache=yes. If it reads opcache=no, change it:
sed -i 's/^opcache=no/opcache=yes/' /usr/local/directadmin/custombuild/options.conf
Replace php82 with your target version (php80, php81, php83):
cd /usr/local/directadmin/custombuild
./build php82
./build php_extensions82
This takes 10–25 minutes depending on server CPU. Do not interrupt the process.
systemctl restart php82-fpm
php82 -m | grep -i opcache
You should see Zend OPcache in the output.
php82 --ini | grep "Scan for additional .ini files"
Common path: /usr/local/lib/php82/conf.d/
cat > /usr/local/lib/php82/conf.d/99-opcache-custom.ini <<'EOF'
; CloudHouse custom OPcache settings - survives CustomBuild rebuilds
[opcache]
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.max_wasted_percentage=5
opcache.use_cwd=1
EOF
php82 -i | grep opcache.memory_consumption
Should return your custom value, not the compiled-in default of 64.
chattr +i /usr/local/lib/php82/conf.d/99-opcache-custom.ini
The +i (immutable) flag prevents any process — including root — from modifying or deleting the file without explicitly removing the attribute first. This is the most reliable protection against CustomBuild overwrites. To edit the file in future, run chattr -i first, make changes, then re-apply chattr +i.
If you rely on our managed DirectAdmin server support, this protection step is part of the standard hardening we apply after every PHP upgrade.
Step 4: Size OPcache Memory for Multi-Site Shared Servers
The most common misconfiguration on shared servers running 10–50 WordPress sites is undersizing opcache.memory_consumption. When the cache fills up, OPcache starts evicting scripts — meaning some requests fall back to the full parse-compile cycle, negating the performance benefit.
Memory Sizing Formula
Required OPcache Memory (MB) = (Average PHP files per site x Number of sites x Average file size in MB) x 1.25 safety margin
WordPress benchmarks by site type:
- Plain WordPress + 10 plugins: ~3,500 PHP files, ~18 MB compiled bytecode per site
- WordPress + WooCommerce + 20 plugins: ~6,500 PHP files, ~35 MB compiled bytecode per site
- WordPress + Elementor + WooCommerce + 30 plugins: ~9,000 PHP files, ~55 MB compiled bytecode per site
Recommended opcache.memory_consumption values:
- 1–5 sites (light plugins):
64MB - 5–15 sites (mixed plugin load):
128MB - 15–30 sites (WooCommerce or page builders):
256MB - 30–50 sites (heavy plugin footprints):
512MB
Scale opcache.max_accelerated_files to match. Use a prime number for optimal hash table performance: 7963, 16229, 32531, 65537.
Count actual PHP files on your server:
find /home -name "*.php" | wc -l
Set max_accelerated_files to the next prime number above this count.
RAM Budget Check
Never allocate more than 25% of total RAM to OPcache alone. On a 4 GB server: max 1 GB. On a 2 GB server: max 512 MB. Leave remaining RAM for PHP-FPM workers, MySQL/MariaDB buffer pool, and OS overhead.
Step 5: Verify OPcache Is Working
Method 1: PHP CLI Status Check
php82 -r "
\$s = opcache_get_status();
echo 'OPcache enabled: ' . (\$s['opcache_enabled'] ? 'YES' : 'NO') . PHP_EOL;
echo 'Used memory: ' . round(\$s['memory_usage']['used_memory']/1024/1024, 1) . ' MB' . PHP_EOL;
echo 'Free memory: ' . round(\$s['memory_usage']['free_memory']/1024/1024, 1) . ' MB' . PHP_EOL;
echo 'Cached scripts: ' . \$s['opcache_statistics']['num_cached_scripts'] . PHP_EOL;
echo 'Cache hits: ' . \$s['opcache_statistics']['hits'] . PHP_EOL;
echo 'Cache misses: ' . \$s['opcache_statistics']['misses'] . PHP_EOL;
"
A healthy server shows used memory well below the allocation limit and a hit-to-miss ratio above 90% after 10–15 minutes of normal traffic.
Method 2: Before/After TTFB Test
# Before enabling OPcache
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s
" https://yourwordpresssite.com/
# After enabling OPcache
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s
" https://yourwordpresssite.com/
Expect a 30–60% reduction in TTFB on a non-cached WordPress page load.
Troubleshooting Common OPcache Issues in DirectAdmin
OPcache active in CLI but not in PHP-FPM web requests
CLI and FPM use separate php.ini loading paths. Create a temporary phpinfo.php file in a site's webroot, verify OPcache is enabled in the web context, then delete the file.
Settings reset after CustomBuild rebuild
Move all OPcache directives to /usr/local/lib/php82/conf.d/99-opcache-custom.ini and apply chattr +i as described in Step 3.
OPcache memory full — hit rate dropping
Check oom_restarts in opcache_get_status(). If non-zero, OPcache has run out of memory and restarted. Increase opcache.memory_consumption using the formula in Step 4.
WordPress plugin updates not reflecting after deployment
With opcache.revalidate_freq=60, updated files may serve stale bytecode for up to 60 seconds. Reset OPcache immediately after a plugin update:
php82 -r "opcache_reset();"
Fatal errors after enabling OPcache
Confirm opcache.save_comments=1. Plugins using PHP annotation-based dependency injection fail when docblock comments are stripped. Also ensure opcache.enable_file_override=0 to avoid include path resolution bugs.
Properly configured OPcache is one of the most cost-effective performance improvements on a DirectAdmin server — it requires no application changes, no additional software licenses, and pays dividends across every WordPress site on the server. By installing via CustomBuild, applying the correct memory sizing formula, and protecting your settings with a conf.d include file and chattr +i, you ensure those gains are permanent and survive every PHP rebuild. If you want these optimizations applied by engineers who manage DirectAdmin servers daily, our team provides expert managed DirectAdmin server support ready to help.
