DirectAdmin Website Running Slow? 6 Performance Fixes for Hosting Admins

Slow websites on a DirectAdmin server hurt everyone: your clients lose conversions, their visitors bounce, and you receive support tickets. Unlike shared hosting where one noisy neighbour causes slowdown, DirectAdmin-managed servers give you direct access to every layer of the stack — which means you can actually fix the root cause. This guide covers 6 proven performance fixes, from enabling PHP opcode caching to tuning MySQL query performance, so websites on your server load fast and stay fast.

Why Are Websites Slow on DirectAdmin?

Before applying fixes, identify the bottleneck. Performance problems on DirectAdmin servers almost always come from one of these sources:

• PHP without OPcache: Every PHP request recompiles scripts from scratch — adds 50–200ms per request
• Untuned Apache configuration: Default Apache settings are conservative — too few concurrent connections, no keep-alive, wrong MPM worker settings
• Slow MySQL queries: WordPress, WooCommerce, and other database-heavy apps cause constant slow queries on untuned MySQL
• No object caching: Every page request hits the database — caching reduces database queries by 90%+ on dynamic sites
• Disk I/O bottleneck: Cheap VPS servers often use shared storage — high disk wait time slows all sites
• ModSecurity or CSF overhead: Security layers add processing time per request — misconfigured rules cause disproportionate slowdowns

Start with top and iostat to identify which resource (CPU, memory, disk) is saturated before applying fixes:

# Check CPU and memory
top

# Check disk I/O
iostat -x 2 5

# Check Apache status
/usr/local/directadmin/custombuild/custom/ap2/httpd -t -D DUMP_MODULES | grep mpm

Fix 1: Enable and Configure OPcache

PHP OPcache is the single highest-impact performance improvement for PHP-based websites (WordPress, Joomla, Magento). It caches compiled PHP bytecode in memory, eliminating the need to parse and compile PHP files on every request. Most DirectAdmin servers have OPcache available but not optimally configured.

Check if OPcache is enabled

php -i | grep opcache.enable

Enable and tune OPcache in php.ini

Find your active php.ini (check php --ini) and add or update these settings:

[opcache]
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
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

Key values to understand:

• memory_consumption=256: 256MB of RAM for the opcode cache — increase to 512 on servers with lots of PHP apps
• max_accelerated_files=10000: How many PHP files can be cached. WordPress + plugins = 5,000–8,000 files per site
• revalidate_freq=60: How often OPcache checks if cached files are still current (seconds). Set to 0 in dev, 60–300 in production

After updating, restart Apache in DirectAdmin: Admin Panel → Administrator Tools → Restart Apache, or from the CLI:

service httpd restart

Fix 2: Tune Apache for Better Performance

Default Apache settings on most DirectAdmin installations use the Prefork MPM with conservative resource limits. For servers with multiple sites, Worker or Event MPM is significantly more efficient.

Check current MPM

httpd -V | grep -i mpm

Switch to Event MPM (via CustomBuild)

DirectAdmin uses CustomBuild to manage Apache versions. To switch MPM:

cd /usr/local/directadmin/custombuild
./build set mpm event
./build apache

Tune Apache worker settings

Edit /etc/httpd/conf/httpd.conf (or the equivalent for your distro) and adjust the MPM section:

<IfModule mpm_event_module>
    StartServers             4
    MinSpareThreads         25
    MaxSpareThreads         75
    ThreadLimit             64
    ThreadsPerChild         25
    MaxRequestWorkers      150
    MaxConnectionsPerChild 1000
</IfModule>

Enable Keep-Alive

Ensure KeepAlive is enabled in Apache config — it allows browsers to reuse connections, reducing overhead per page load:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

Enable mod_deflate and mod_expires for gzip compression and browser caching — these reduce page payload by 60–80%:

# Enable modules (via CustomBuild)
cd /usr/local/directadmin/custombuild
./build set deflate yes
./build apache

Fix 3: Optimize MySQL/MariaDB Settings

Default MySQL settings are tuned for minimal memory usage, not performance. On a DirectAdmin server with multiple WordPress or eCommerce sites, the InnoDB buffer pool is the most important setting to tune.

# Check current buffer pool size
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

# Identify slow queries
mysql -e "SHOW FULL PROCESSLIST;" | grep -v Sleep

Edit /etc/my.cnf and update these settings (adjust values based on your server's total RAM):

[mysqld]
# InnoDB buffer pool: set to 50-70% of total RAM
innodb_buffer_pool_size = 1G

# Buffer pool instances (one per GB of buffer pool)
innodb_buffer_pool_instances = 1

# Query cache (disable on MySQL 8+, tune on MariaDB)
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M

# Temporary tables
tmp_table_size = 64M
max_heap_table_size = 64M

# Connections
max_connections = 150
thread_cache_size = 16

After saving, restart MySQL:

service mysqld restart

Enable the MySQL Slow Query Log

Find which queries are slowing your sites:

mysql -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;"
# Queries slower than 1 second will log to /var/lib/mysql/hostname-slow.log

Fix 4: Enable Object Caching with Redis

For WordPress sites, WooCommerce stores, and other PHP CMS platforms, object caching with Redis dramatically reduces the number of database queries per page load. Without caching, a WordPress site makes 50–100 database queries per visit. With Redis object caching, most of those are served from memory.

Install Redis

# CentOS/AlmaLinux
yum install redis -y
systemctl enable redis
systemctl start redis

# Ubuntu/Debian
apt install redis-server -y
systemctl enable redis-server
systemctl start redis-server

Install PHP Redis extension

cd /usr/local/directadmin/custombuild
./build set php_extensions redis
./build php

Configure WordPress to use Redis

Install the Redis Object Cache WordPress plugin, then add to wp-config.php:

define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

Enable the plugin in WordPress Admin → Settings → Redis. Once enabled, database queries that would normally take 100–200ms are served from Redis in under 1ms.

Fix 5: Check and Fix Disk I/O Issues

On VPS servers (Vultr, Linode, DigitalOcean), shared disk storage can create I/O bottlenecks that no amount of PHP or MySQL tuning can fix — because the wait is at the hardware level.

# Check disk I/O wait
iostat -x 1 5
# High %iowait (over 20%) indicates disk bottleneck

# Check which processes are causing disk I/O
iotop -o

# Check if disk is nearly full (full disk = severe slowdown)
df -h

If you see consistently high I/O wait and can't upgrade to faster disk, these software-level changes help:

• Use tmpfs for PHP sessions: Store PHP sessions in memory instead of disk — edit /etc/php.ini: session.save_path = /dev/shm/php-sessions
• Move MySQL tmpdir to tmpfs: In /etc/my.cnf: tmpdir = /dev/shm
• Enable Nginx as a reverse proxy: Serve static files (CSS, JS, images) via Nginx instead of Apache — Nginx uses much less memory per connection and is far more efficient for static content

Enable Nginx as Reverse Proxy in DirectAdmin

cd /usr/local/directadmin/custombuild
./build set nginx yes
./build set webserver nginx_apache
./build nginx
./build apache

Fix 6: Audit ModSecurity and CSF Firewall Impact

ModSecurity (the Apache web application firewall) is enabled by default on many DirectAdmin servers and adds 20–50ms of processing overhead per request. With default OWASP rules, false positives can cause certain PHP scripts to take 5–10× longer to process.

# Check if ModSecurity is enabled
httpd -M | grep security

# Check ModSecurity audit log for false positives
tail -100 /var/log/httpd/modsec_audit.log | grep -i "warning\|error"

If ModSecurity is causing significant overhead, consider switching from DetectionOnly mode to tuned rules, or disabling specific OWASP rules that fire frequently on legitimate traffic. In DirectAdmin, you can configure this under Admin Panel → ModSecurity.

Similarly, CSF (ConfigServer Firewall) with aggressive connection tracking can add latency. Check CSF settings:

# View CSF connection tracking
csf -l | head -20

# Adjust CT_LIMIT (connection tracking threshold) in /etc/csf/csf.conf
CT_LIMIT = "300"  # default is often 300

If you've applied these fixes and sites are still slow, the bottleneck may be at the server hardware level or require per-site profiling. CloudHouse's server management team can perform a complete performance audit of your DirectAdmin server — identifying slow queries, misconfigured modules, and I/O bottlenecks — and implement a tuning plan tailored to your workload.

FAQs