If your PHP sites feel sluggish and your DirectAdmin server's CPU is working harder than it should, the root cause is almost always the same: PHP is recompiling the same scripts from raw source code on every single page request. A proper DirectAdmin OPcache setup eliminates that redundant work, keeps compiled bytecode in shared memory, and can cut PHP execution time by 50–80% without touching a line of application code. This guide goes well beyond the basic install command — you will get production-tuned configuration values, guidance on stacking Redis object caching alongside OPcache, and a repeatable monitoring workflow to keep performance dialled in as your server grows.
What OPcache Does and Why It Matters on DirectAdmin Servers
PHP is an interpreted language. Without any caching layer, the PHP engine follows the same four-step process for every request: read the source file from disk, parse it into tokens, compile those tokens into opcodes, and run the opcodes. For a single request to a WordPress homepage, this cycle may repeat across dozens of included files.
OPcache short-circuits steps one through three. After the first request, the compiled opcodes for each PHP file are stored in shared memory. Subsequent requests skip straight to execution — the disk read, parse, and compile overhead simply disappears.
- CPU load drops — compilation is computationally expensive. Removing it from the hot path reduces CPU utilisation across the board.
- Response times improve — pages that took 300–600 ms to generate often drop to 80–150 ms with OPcache alone.
- Memory efficiency improves — shared opcode memory is shared across all PHP worker processes, so 100 workers serving the same WordPress install all read from one cached copy.
- Hosting density increases — with lower CPU overhead per request, a single DirectAdmin server can comfortably handle more sites and more concurrent traffic.
OPcache has shipped bundled with PHP since version 5.5, so you are activating a first-party performance feature that is already present on your server. As part of a comprehensive managed server management service, enabling and tuning OPcache is one of the first optimisations applied to any new DirectAdmin environment.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Installing OPcache via DirectAdmin CustomBuild 2.0
DirectAdmin uses CustomBuild 2.0 as its software build system, and it is the correct tool for enabling OPcache rather than manually editing extension configurations.
ssh root@your-server-ip
cd /usr/local/directadmin/custombuild
./build options | grep php
cat options.conf | grep -i opcache
nano /usr/local/directadmin/custombuild/options.conf
Find the opcache directive and set it to yes:
opcache=yes
./build php 8.1
./build php 8.2
CustomBuild will compile PHP with the --enable-opcache flag. This step takes several minutes per PHP version.
service php-fpm81 restart
service php-fpm82 restart
service httpd restart
If you are running LiteSpeed instead of Apache:
service lsws restart
If OPcache Was Already Compiled In
On many DirectAdmin servers, OPcache is compiled into PHP but disabled at the ini level. Confirm the opcache.enable=1 directive is present in the active PHP ini file, then restart PHP-FPM. The verification steps in the next section will clarify which situation applies to you.
Verifying OPcache Is Active with phpinfo() and opcache_get_status()
Method 1: phpinfo()
Create a temporary PHP file in a web-accessible directory:
<?php phpinfo(); ?>
Load it in a browser and search for OPcache. You should see Opcode Caching: Up and Running. Delete this file immediately after checking — never leave a phpinfo() file accessible on a production server.
Method 2: CLI Status Check
php -r "var_dump(opcache_get_status());"
If OPcache is active, you will see a detailed array including opcache_enabled: bool(true). If the function does not exist, OPcache is not loaded.
Confirming the Correct ini File
php8.1 --ini | grep "Loaded Configuration"
Open that file and confirm these two directives are present:
zend_extension=opcache.so
opcache.enable=1
Optimal OPcache Configuration Settings for Production Servers
The default OPcache settings are conservative — designed to be safe on minimal hardware, not to maximise throughput on a production server. Place these settings in your PHP ini file or a dedicated /etc/php.d/opcache.ini drop-in file.
Core Memory and Capacity Settings
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.max_wasted_percentage=10
opcache.use_cwd=1
opcache.memory_consumption— Shared memory for compiled opcodes in MB. Low-traffic (1–5 sites): 128 MB. Medium-traffic (5–20 sites): 256 MB. High-traffic / large apps: 512 MB. When this fills up, OPcache begins evicting scripts — hit rates drop and CPU climbs.opcache.interned_strings_buffer— Memory for caching interned strings (function names, variable names). 16 MB is appropriate for most servers; increase to 32 MB for many large applications.opcache.max_accelerated_files— Maximum PHP scripts OPcache will cache. A server with 20 WordPress sites needs 60,000–100,000 slots available. Set this higher than your actual file count — running out causes evictions.opcache.max_wasted_percentage— When this percentage of memory contains invalidated scripts, OPcache triggers a cache restart. 10% is a sensible default.
Revalidation and Timestamp Settings
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.revalidate_path=0
opcache.save_comments=1
opcache.validate_timestamps=1— Tells OPcache to check whether PHP source files have changed. Essential on production servers where files are occasionally updated.opcache.revalidate_freq=60— How often (in seconds) OPcache checks for file changes. Development: 0 (every request). Production, low-change sites: 120–300 seconds. Production, frequent deployments: 0 (clear cache manually on deploy).opcache.save_comments=1— Required by Doctrine ORM, Laravel, and Symfony that use docblock annotations. Never set to 0 unless you are certain your stack does not use annotation-based features.
JIT Compilation (PHP 8.x Only)
PHP 8.0 introduced Just-In-Time compilation as an OPcache sub-feature. For CPU-intensive workloads (image processing, data transformation), JIT can be significant.
opcache.jit=tracing
opcache.jit_buffer_size=64M
Start with tracing mode — it profiles at runtime and compiles the hottest code paths. If you see no measurable improvement after a week of traffic, disabling JIT recovers the buffer memory for standard OPcache use.
How to Enable Redis as an Object Cache Alongside OPcache
OPcache solves PHP compilation overhead. It does not solve database query overhead — every request that hits WordPress or a custom PHP application still fires SQL queries against MySQL. Redis object caching addresses this second bottleneck, and the two layers work together without conflict.
Install the Redis PHP Extension via CustomBuild
cd /usr/local/directadmin/custombuild
./build redis
./build php_extension redis 8.1
./build php_extension redis 8.2
Restart PHP-FPM after the build completes.
Confirm Redis Is Running
redis-cli ping
Expected response: PONG. If Redis is not installed:
# CentOS / AlmaLinux / Rocky Linux
yum install redis -y
systemctl enable redis --now
# Ubuntu / Debian
apt install redis-server -y
systemctl enable redis --now
Configure WordPress to Use Redis Object Cache
Install the Redis Object Cache plugin by Till Krüss. Once activated, add to wp-config.php:
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_CACHE', true);
Then click Enable Object Cache in the plugin's settings. WordPress now stores expensive database query results in Redis. Combined with OPcache handling PHP compilation, you have eliminated the two largest sources of redundant work on a PHP/MySQL stack.
Using Redis for PHP Sessions
Storing PHP sessions in Redis instead of on disk improves performance on high-concurrency servers. Add to your PHP ini:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=1"
Our managed server management service includes Redis configuration and ongoing tuning as standard — the OPcache and Redis layers are always set up together because neither alone captures the full performance benefit.
Monitoring OPcache Hit Rates and Tuning Memory Consumption
Configuration without monitoring is guesswork. OPcache exposes detailed runtime statistics via opcache_get_status().
Reading opcache_get_status() Output
<?php
$status = opcache_get_status(false);
$mem = $status['memory_usage'];
$stats = $status['opcache_statistics'];
printf("Hit rate: %.2f%%
", $stats['opcache_hit_rate']);
printf("Hits: %d
", $stats['hits']);
printf("Misses: %d
", $stats['misses']);
printf("Cached scripts: %d
", $stats['num_cached_scripts']);
printf("Used memory: %.1f MB
", $mem['used_memory'] / 1048576);
printf("Free memory: %.1f MB
", $mem['free_memory'] / 1048576);
printf("Wasted %%: %.2f%%
", $mem['current_wasted_percentage']);
?>
Interpreting the Numbers
- Hit rate above 95% — OPcache is working well.
- Hit rate 85–95% — Investigate whether
max_accelerated_filesis too low or memory is filling up. - Hit rate below 85% — Increase
memory_consumptionand/ormax_accelerated_files. - Used memory above 80% of total — Increase
memory_consumptionbefore it fills completely and evictions begin.
Clearing OPcache After Deployments
When you push code changes, OPcache may serve stale compiled bytecode until the next revalidation cycle. For zero-stale deployments, restart PHP-FPM with a graceful signal:
service php-fpm81 graceful
service php-fpm82 graceful
The graceful signal causes PHP-FPM to finish in-flight requests before reloading workers — no downtime, and the opcode cache is fully flushed in the process.
Getting OPcache and Redis properly configured on a DirectAdmin server is one of the highest-return investments you can make in PHP performance — no application code changes required, no hardware upgrades needed. If you would rather have an expert handle the setup, tuning, and ongoing monitoring, our team provides exactly that as part of a fully managed server management service. Reach out today and we will have your DirectAdmin server running at peak efficiency within hours.
