Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 2: PHP & Runtime — Part 8 of 30

Why Your WordPress Site Is Slow Even With OPcache Enabled

Introduction

Enabling OPcache is a standard recommendation for WordPress performance, but many sysadmins on DirectAdmin with Rocky Linux 9 find their sites remain sluggish. This article explains why OPcache alone isn’t enough, how DirectAdmin’s PHP-FPM and webserver configs affect behavior, and step-by-step methods to diagnose and resolve slow WordPress sites despite OPcache being active.

How OPcache Works and Its Limitations

OPcache caches precompiled PHP scripts in memory, reducing PHP execution time. However, it only accelerates PHP opcode loading. It does not address:

• Slow MySQL queries
• Poor PHP-FPM pool tuning
• Excessive plugins/themes
• Unoptimized object/page caching
• Web server misconfiguration
• High resource usage by other users (on shared hosting)

DirectAdmin-Specific Considerations

• DirectAdmin manages PHP-FPM pools per domain/user and deploys webserver configs from templates.
• OPcache settings can be overridden on a per-domain or per-user basis.
• Default PHP-FPM pools are often under-tuned for busy or resource-intensive WordPress instances.
• DirectAdmin’s default webserver templates may not be optimal for WordPress performance.

Checklist: Confirming OPcache Is Actually Enabled and Used

1. Check OPcache status for the site’s PHP version:

   sudo -u <user> php -i | grep opcache

   Replace <user> with the domain’s user. For multi-PHP, use php81, php82, etc.
2. Verify OPcache is active in the relevant FPM pool:

   grep opcache /usr/local/php*/lib/php.ini
   grep opcache /usr/local/php*/etc/php-fpm.d/*.conf

3. Use WP-CLI to confirm OPcache usage from WordPress context:

   cd /home/<user>/domains/<domain>/public_html
   wp eval 'var_dump(opcache_get_status());'

Common Reasons for Slowness Despite OPcache

1. PHP-FPM Pool Misconfiguration

DirectAdmin creates per-domain PHP-FPM pools, but default settings are conservative. A busy site may experience:

• Too few PHP workers (pm.max_children) causing request queuing
• Insufficient memory allocation leading to FPM process recycling
• OPcache memory pool exhaustion (scripts not cached, frequent cache purges)

Checklist: Tune PHP-FPM and OPcache for Your Site

1. Locate the PHP-FPM pool config for the domain: /usr/local/php*/etc/php-fpm.d/<user>.conf
2. Edit OPcache and pool settings (adjust for your resources):

pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 10s
php_admin_value[opcache.memory_consumption] = 192
php_admin_value[opcache.interned_strings_buffer] = 16
php_admin_value[opcache.max_accelerated_files] = 10000
php_admin_value[opcache.revalidate_freq] = 60

• For busy sites, increase pm.max_children and OPcache memory, but monitor RAM usage.

3. Restart PHP-FPM to apply changes (risk: brief downtime for PHP apps):

   sudo systemctl restart php-fpm81.service

   Replace 81 with your PHP version.

2. Web Server Bottlenecks (NGINX/Apache)

DirectAdmin supports both Apache and NGINX. Default configs may not be optimal for high-traffic WordPress:

• Low worker limits (MaxRequestWorkers for Apache, worker_processes for NGINX)
• Missing cache headers, GZIP, or static file optimizations

Checklist: Improve Web Server Configuration

1. Locate/customize DirectAdmin template for your stack: Apache: /usr/local/directadmin/data/templates/custom/httpd-php-fpm.conf NGINX: /usr/local/directadmin/data/templates/custom/nginx_php.conf
2. Set good defaults (example for NGINX):

worker_processes auto;
worker_connections 1024;
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
}

3. Rebuild configs and reload your webserver (risk: brief downtime if syntax errors):

   sudo ./build rewrite_confs
   sudo systemctl reload nginx
   sudo systemctl reload httpd

   Only reload the services you use.

3. MySQL/MariaDB Query Slowdowns

OPcache does not accelerate database queries. Slow queries, missing indexes, or overloaded DB servers will cause slowness.

• Enable and review the slow query log:

sudo vim /etc/my.cnf.d/server.cnf
# Add or edit:
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql-slow.log
long_query_time = 2

• Restart MariaDB:

sudo systemctl restart mariadb

• Analyze slow queries:

sudo tail -f /var/log/mysql-slow.log

Resolve by optimizing queries, adding indexes, or tuning DB server resources.

4. Inefficient WordPress Plugins or Themes

Heavy plugins, poorly coded themes, or excessive plugin count will degrade performance, regardless of OPcache.

Checklist: Audit and Optimize Plugins/Themes

1. List all plugins and their status:

wp plugin list --status=active --path=/home/<user>/domains/<domain>/public_html

2. Temporarily disable non-essential plugins and measure impact:

wp plugin deactivate <plugin-slug> --path=/home/<user>/domains/<domain>/public_html

3. Switch to a default theme for testing:

wp theme activate twentytwentyfour --path=/home/<user>/domains/<domain>/public_html

If performance improves, identify and replace problematic plugins/themes.

5. Lack of Object Caching

OPcache does not cache persistent objects (queries, transients). For busy WordPress sites, enable Redis or Memcached object caching.

1. Install Redis server (safe to install, but do not expose to public interfaces):

sudo dnf install redis
sudo systemctl enable --now redis
sudo firewall-cmd --zone=public --add-port=6379/tcp --permanent
sudo firewall-cmd --reload

2. Install and configure redis-cache plugin:

wp plugin install redis-cache --activate --path=/home/<user>/domains/<domain>/public_html
wp redis enable --path=/home/<user>/domains/<domain>/public_html

Monitor object cache hit rates in the plugin dashboard or via wp redis info.

Testing Performance Changes

After each tuning step, benchmark and review logs to validate improvements.

• Use curl for basic response times:

curl -o /dev/null -s -w "%{time_total}
" https://yourdomain.tld/

• Use wrk for concurrent load testing (install: sudo dnf install wrk):

wrk -t4 -c40 -d30s https://yourdomain.tld/

• Monitor logs for errors or slow events:

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/httpd/error_log
sudo journalctl -u php-fpm81 -f

Test with WP-CLI to ensure backend actions are also faster:

wp eval 'echo "Test";' --path=/home/<user>/domains/<domain>/public_html

Summary: OPcache Is Only One Part of the Stack

• Ensure OPcache is enabled, sized, and working for each PHP-FPM pool.
• Tune PHP-FPM and webserver configs for your workload and resource limits.
• Audit plugins/themes and enable persistent object caching.
• Benchmark and iterate: only change one variable at a time for clear results.

Note: This article offers general technical guidance. Validate all configurations in a safe environment before applying them to production.

Previous: OPcache Explained: How to Properly Enable and Tune It for WordPress

Next: Understanding WordPress Object Cache (Without the Myths)