How to Enable and Tune PHP OPcache in DirectAdmin for Maximum Performance

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.

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

opcache=yes

./build php 8.1
./build php 8.2

service php-fpm81 restart
service php-fpm82 restart
service httpd restart

service lsws restart

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_files is too low or memory is filling up.
• Hit rate below 85% — Increase memory_consumption and/or max_accelerated_files.
• Used memory above 80% of total — Increase memory_consumption before 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.