Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 7: Themes, Gutenberg & Measurement — Part 28 of 30

How to Measure Real WordPress Performance (Not PageSpeed Scores)

Understanding the true performance of your WordPress installation on DirectAdmin (Rocky Linux 9) requires more than chasing high PageSpeed or Lighthouse scores. While synthetic metrics are useful, they do not represent how your server and application respond under realistic load or in production scenarios. This article outlines practical, engineering-focused steps to accurately measure real-world WordPress performance at the system, PHP-FPM, web server, and application levels, with DirectAdmin-specific considerations.

Why PageSpeed Scores Are Not Enough

• PageSpeed Insights focuses on front-end aspects (JS/CSS, images, browser hints) and emulated loads, not actual server throughput or backend latency.
• DirectAdmin-managed environments have backend-specific bottlenecks (PHP-FPM pool limits, per-domain resource allocation, NGINX/Apache template configs) that PageSpeed can’t assess.
• Real users experience delays from server-side performance, not just static asset optimization.

DirectAdmin & Rocky Linux 9: Key Performance Surfaces

• PHP-FPM: Each domain typically gets its own pool with DirectAdmin, configurable in /usr/local/directadmin/data/users/<username>/php-fpmXX.conf. Pool size, process limits, and memory usage directly affect concurrency and response times.
• Web Server: NGINX and Apache configs are controlled by DirectAdmin templates (e.g., /usr/local/directadmin/data/templates/nginx_server.conf). Template changes may require rebuilding configs—always backup templates before editing.
• OS & Network: Rocky Linux 9 optimizations (sysctl, firewalld, dnf-managed packages) impact baseline resource efficiency and security.

Checklist: Measuring Real WordPress Performance

1. Establish Baselines:
   • Get current PHP-FPM, NGINX/Apache, MySQL process stats.
   • Record load averages, memory usage, and network throughput.
2. Simulate Real Traffic:
   • Use curl, wrk, or k6 to generate HTTP requests.
   • Measure time to first byte (TTFB), total response time, error rates.
3. Monitor Logs:
   • Tail PHP-FPM, NGINX/Apache, and WordPress error logs for slow requests or failures.
4. Analyze Application Latency:
   • Use WP-CLI to time backend operations (e.g., wp option get, wp post list).
5. Iterate & Compare:
   • Adjust configs, retest, and measure improvements.

Step 1: Establish a Baseline

System Load and PHP-FPM Pool Status

sudo dnf install -y htop iotop
htop
iotop -o

Check PHP-FPM pool status (replace php81 with your version):

sudo systemctl status php-fpm81
sudo tail -f /var/log/php-fpm/www-error.log

List active PHP-FPM pools:

ls /usr/local/directadmin/data/users/*/php-fpm*.conf

Web Server Status

For NGINX (DirectAdmin default on many setups):

sudo systemctl status nginx
sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

For Apache:

sudo systemctl status httpd
sudo tail -f /var/log/httpd/access_log
sudo tail -f /var/log/httpd/error_log

Database Stats

sudo systemctl status mariadb
sudo mysql -e "SHOW PROCESSLIST;"

Step 2: Simulate Realistic Load

Simple Single Request (TTFB, Total Time)

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s
Total: %{time_total}s
" https://yourdomain.com/

Concurrent Load Testing with wrk

wkr is a fast HTTP benchmarking tool. Install and run:

sudo dnf install -y epel-release
sudo dnf install -y wrk

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

• -t4: 4 threads
• -c40: 40 concurrent connections
• -d30s: 30 seconds test duration

Review requests per second, latency percentiles, and error rates.

Advanced Load Testing with k6 (Optional)

sudo dnf install -y k6
k6 run --vus 50 --duration 30s --summary-trend-stats="avg,p(95),p(99)" <(echo '
import http from "k6/http";
export default function () {
  http.get("https://yourdomain.com/");
}
')

Step 3: Application-Level Performance with WP-CLI

Check WordPress backend response time for basic queries:

cd /home/<user>/domains/<domain>/public_html
wp option get siteurl --debug
wp post list --fields=ID,post_title,post_status --per_page=10 --debug

Note time taken for each command. If WP-CLI is slow, check for excessive plugins, autoloaded options, or DB bloat.

Step 4: Monitor and Analyze Logs

• PHP-FPM slowlog (ensure slowlog is enabled in pool config):

sudo grep -r slowlog /usr/local/directadmin/data/users/*/php-fpm*.conf
sudo tail -f /var/log/php-fpm/www-slow.log

• NGINX/Apache error and access logs (look for 5xx errors, slow requests):

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/httpd/error_log

• WordPress debug log (if enabled):

sudo tail -f /home/<user>/domains/<domain>/public_html/wp-content/debug.log

Step 5: Tune and Retest

PHP-FPM Pool Tuning (DirectAdmin)

Edit the pool config for your domain (replace placeholders):

sudo vi /usr/local/directadmin/data/users/<user>/php-fpm81.conf

• Good starting values:
• • pm = ondemand
  • pm.max_children = 10 (increase for high concurrency, but monitor memory usage)
  • pm.process_idle_timeout = 10s

Note: Modifying PHP-FPM configs and reloading the service will briefly interrupt PHP request handling (downtime risk). If using DirectAdmin’s custom templates, changes may be overwritten by the panel. Always back up the original file.

sudo systemctl reload php-fpm81

Web Server Config (NGINX/Apache)

For per-domain or global tweaks (e.g., buffer sizes, timeouts), edit the appropriate DirectAdmin template:

sudo cp /usr/local/directadmin/data/templates/nginx_server.conf /usr/local/directadmin/data/templates/custom/nginx_server.conf
sudo vi /usr/local/directadmin/data/templates/custom/nginx_server.conf

After changes, rebuild configs and reload the server:

sudo /usr/local/directadmin/custombuild/build rewrite_confs
sudo systemctl reload nginx

Downtime warning: Syntax errors in templates will prevent NGINX/Apache from restarting. Validate templates before reloading.

Summary and Recommendations

• Always test changes in a staging environment before applying to production.
• Measure actual server response under load, not just single-user synthetic benchmarks.
• Monitor PHP-FPM and web server logs for slow requests and errors during your tests.
• Iterate configuration changes, documenting each step and its impact on performance metrics.
• Combine system-level, web server, and application-level metrics for a complete view.

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

Further Reading

• Earlier in this series: DirectAdmin PHP-FPM Pool Optimization
• Next: Profiling WordPress Themes and Gutenberg for Backend Latency

Previous: Optimising Gutenberg for Faster WordPress Admin Experience

Next: The Complete WordPress Performance Checklist