How to Configure PHP OPcache in DirectAdmin for Faster WordPress Sites (2025 Guide)

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 version to confirm.
• Root SSH access: All steps require root or sudo privileges.
• Available RAM: At least 128 MB free beyond existing usage. Run free -h to 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.

Step 1: Install OPcache via DirectAdmin CustomBuild 2.0

grep opcache /usr/local/directadmin/custombuild/options.conf

sed -i 's/^opcache=no/opcache=yes/' /usr/local/directadmin/custombuild/options.conf

cd /usr/local/directadmin/custombuild
./build php82
./build php_extensions82

systemctl restart php82-fpm
php82 -m | grep -i opcache

php82 --ini | grep "Scan for additional .ini files"

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

chattr +i /usr/local/lib/php82/conf.d/99-opcache-custom.ini

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): 64 MB
• 5–15 sites (mixed plugin load): 128 MB
• 15–30 sites (WooCommerce or page builders): 256 MB
• 30–50 sites (heavy plugin footprints): 512 MB

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.