Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 5: Apache & Server Layer — Part 20 of 30

How to Identify Slow Apache Requests in a WordPress Site

Overview

Identifying slow Apache requests is essential for diagnosing WordPress performance issues, especially on DirectAdmin-managed Rocky Linux 9 servers. This guide details practical, safe methods to pinpoint bottlenecks, interpret log data, and tune Apache settings relevant to DirectAdmin’s environment—including PHP-FPM and per-domain configuration.

Why Focus on Slow Requests?

Slow requests impact user experience and server resource utilization. On DirectAdmin systems, identifying these requests enables targeted tuning per domain, pool, or template, reducing troubleshooting time and minimizing risk to production sites.

DirectAdmin and Rocky Linux 9: Key Considerations

• Apache/Nginx Integration: DirectAdmin may use NGINX as a reverse proxy in front of Apache. Check your setup with sudo directadmin custombuild.
• PHP-FPM Pools: Each domain typically has its own PHP-FPM pool. Logs and performance metrics can be isolated per site.
• Log Paths: On EL9, logs are usually under /var/log/httpd/ for Apache and /var/log/nginx/ for NGINX.
• Template-driven Configs: DirectAdmin manages configs using templates. Manual changes may be overwritten—prefer editing templates when making persistent changes.

Step 1: Enable Apache Access and Slow Request Logging

First, ensure Apache logs request times. By default, DirectAdmin’s Apache config logs to /var/log/httpd/domains/ per domain. To log request durations (in microseconds), confirm the log format includes %D or %T:

LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" %D" combined

Check your domain’s custom_log.conf template (usually /usr/local/directadmin/data/templates/custom_log.conf) or the main Apache config. If you update the template, rebuild configs:

cd /usr/local/directadmin/custombuild
sudo ./build rewrite_confs

Downtime warning: Reloading or restarting Apache (sudo systemctl reload httpd) may cause brief connection drops.

Step 2: Identify Slow Requests via Log Analysis

Requests taking more than 1 second (1,000,000 microseconds) are typically considered slow. To extract slow requests for a domain (replace example.com as needed):

sudo awk '$NF > 1000000' /var/log/httpd/domains/example.com.log | less

Count slow requests:

sudo awk '$NF > 1000000' /var/log/httpd/domains/example.com.log | wc -l

For a live tail showing only slow requests:

sudo tail -F /var/log/httpd/domains/example.com.log | awk '$NF > 1000000'

Step 3: Pinpoint Problem Endpoints

To identify which URIs are slowest:

sudo awk '$NF > 1000000 {print $7}' /var/log/httpd/domains/example.com.log | sort | uniq -c | sort -nr | head -20

This highlights the top offending paths (e.g., /wp-admin/admin-ajax.php or slow plugin endpoints).

Step 4: Correlate with PHP-FPM Slowlog (Per-Domain)

Each site’s PHP-FPM pool logs slow scripts. Check your PHP-FPM pool config, typically at /usr/local/phpXX/etc/php-fpm.d/example.com.conf (replace XX with your PHP version). Look for:

slowlog = /var/log/php-fpm/example.com-slow.log
request_slowlog_timeout = 5s

If not set, add or adjust these values. Good starting point: request_slowlog_timeout = 5s.

Apply changes and reload PHP-FPM:

sudo systemctl reload php-fpm

Analyze the slow log for backtraces and slow scripts:

sudo less /var/log/php-fpm/example.com-slow.log

Note: Editing pool configs may be overwritten by DirectAdmin template rebuilds. Update php-fpm.conf templates in /usr/local/directadmin/data/templates/ for persistence.

Step 5: Test and Benchmark After Changes

After making changes or identifying slow endpoints, benchmark site performance to confirm improvements.

Use WP-CLI for Repeatable Tests

cd /home/example/domains/example.com/public_html
wp eval 'echo "Test OK
";'

External Testing Tools

• cURL (single request):

  curl -w "@curl-format.txt" -o /dev/null -s "https://example.com/path"

• wget (timing):

  wget --server-response --no-check-certificate -O /dev/null https://example.com/path

• wrk (load):

  wrk -t2 -c10 -d30s --latency https://example.com/

• k6 (scripting):

  k6 run script.js

Check Apache and PHP-FPM logs after running tests to validate improvements.

Step 6: Review Server Resource Utilization

Slow requests can also be caused by resource exhaustion.

• Monitor real-time resource usage:

  sudo dnf install -y htop
  htop

• Check Apache process status:

  sudo systemctl status httpd

• Review PHP-FPM pool status (if enabled):

  curl http://127.0.0.1:9000/status

  (requires configuration)

Step 7: Tune Apache per Domain (DirectAdmin)

For persistent, per-domain tuning, edit custom templates:

1. Copy template to custom (if not already):

   sudo cp /usr/local/directadmin/data/templates/httpd-vhost.conf /usr/local/directadmin/data/templates/custom/httpd-vhost.conf

2. Edit the custom template as needed.
3. Rebuild configs:

   cd /usr/local/directadmin/custombuild
   sudo ./build rewrite_confs

Common Apache tuning parameters:

• Timeout: Default 60s. Lower to 30s if appropriate.
• KeepAlive: On by default. Tune KeepAliveTimeout (1–5s is typical).
• MaxRequestWorkers: Set based on available RAM. Start around 50–150.

Reload Apache after changes:

sudo systemctl reload httpd

Downtime warning: Apache reloads are generally safe, but restart may cause brief downtime.

Checklist: Identifying Slow Apache Requests (Summary)

• Confirm Apache logs include request time (%D or %T).
• Analyze logs for slow requests (threshold: >1s).
• Identify problematic endpoints by URI.
• Check PHP-FPM slow logs per domain.
• Benchmark after changes (WP-CLI, curl, wrk, k6).
• Monitor server resource usage (htop, status).
• Persist changes via DirectAdmin templates where needed.

Next Steps and Further Reading

Once slow requests are identified, proceed to isolate slow plugins, themes, or external integrations. In the next phase, we’ll cover optimizing Apache worker models and PHP-FPM settings for better concurrency and resilience on DirectAdmin (Rocky Linux 9).

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

Previous: HTTP/2 and HTTP/3 on WordPress: What Actually Improves Speed

Next: WordPress Caching Layers Explained: OPcache vs Redis vs Page Cache