WordPress Performance Optimization: A Complete Guide from Stress Testing to PHP-FPM Tuning

Introduction: Choosing Online Stress Testing Tools

For an initial performance assessment without installing local software, consider online stress testing tools. Options include webkaka.com (for users in China), Loader.io, LoaderNinja, and GTmetrix. These tools help you quickly evaluate your site's behavior under concurrent access.

Problem Diagnosis: Locating Performance Bottlenecks

1. Initial Symptoms and Environment

Test Environment: CentOS 5.6 64-bit, LNMP 1.2, WordPress 4.2
Core Issue: Low concurrent processing capacity; users experienced long wait times after clicking, making the site feel slow.
Quantitative Metrics: Under normal conditions, homepage execution time was ~500ms with ~85 database queries. Under simulated concurrent load via online tools, execution time spiked above 2 seconds, followed by complete service unresponsiveness.

2. First Suspect: Database

Initial suspicion fell on excessive or inefficient MySQL queries.

• Enable Slow Query Log: Modify the MySQL configuration file my.cnf to enable slow query logging.
• Optimize Cache Parameters: Adjust query_cache_size, innodb_buffer_pool_size, and related parameters.

Result: Limited performance improvement. Under 50 concurrent users, phpMyAdmin monitoring showed over 1500 queries, but MySQL processes were not locked.

3. Deep Analysis of Slow Queries

Using Percona Toolkit (e.g., pt-query-digest) to analyze the slow query log revealed most queries took milliseconds, with only one query taking 2 seconds. However, optimizing or eliminating that specific query did not resolve the overall concurrent crash issue.

4. Key Turning Point: Focus on System Resources

Re-examining basic metrics uncovered a critical, overlooked issue: extremely high CPU usage and system load.

Verification Method: Initiate a 50-concurrent-user test using an online tool while simultaneously logging into the server via SSH and running the top command.

Discovery: Several php-fpm processes were consuming nearly all CPU resources, preventing the system from handling new requests. The root cause shifted from the database to the PHP processing layer.

Solution: PHP-FPM and Application Optimization

1. Adjust PHP-FPM Configuration (Initial Attempt)

The first thought was insufficient php-fpm child processes. The configuration file (typically /usr/local/php/etc/php-fpm.conf or /etc/php-fpm.d/www.conf) was modified to increase the pm.max_children value, and the service was restarted.

Result: While individual php-fpm process CPU consumption decreased slightly, the total CPU usage remained near 100% due to the increased number of processes. Memory usage stayed normal. This indicated the bottleneck was CPU computational capacity, not simply process count configuration.

2. Root Cause Solution: Identify the Problematic Plugin

Upgrading the VPS (e.g., from single-core to multi-core) could provide temporary relief but was not a fundamental solution. The real fix required examining the WordPress application itself.

Troubleshooting Method: In the WordPress admin panel, use a binary search or disable plugins one by one, repeating the stress test after each change.

Final Discovery: Disabling the WP-Touch plugin (used for creating mobile themes) resulted in a dramatic improvement in concurrent handling capacity. Response times under 50 concurrent users returned to normal, and CPU load dropped significantly.

Summary and Recommendations

1. Diagnostic Order: Follow a "outside-in, system-to-application" sequence: Network → System Resources (CPU, Memory, I/O) → Web Service (Nginx/Apache) → PHP Processes → Database → Application (WordPress & plugins/themes).
2. Tool Usage: Utilize top, htop, vmstat for system monitoring; slow query logs and Percona Toolkit for database analysis; online tools for non-intrusive stress testing.
3. Optimization Focus: High CPU load under concurrency often indicates inefficient code or blocking operations within the application (or a specific plugin). Blindly increasing php-fpm processes or upgrading hardware only addresses symptoms.
4. Plugin Management: Regularly audit WordPress plugins. Deactivate non-essential or known performance-heavy plugins. For essential but poorly performing plugins, seek alternatives.
5. Configuration Reference (Modern Environments): For LNMP/LAMP environments, besides adjusting pm.max_children, also configure pm.start_servers, pm.min_spare_servers, pm.max_spare_servers, and pm.max_requests (to prevent memory leaks).

Note: This article is based on an older software environment (CentOS 5.6, WordPress 4.2). Current (post-2023) mainstream environments have changed significantly. Testing and optimization are recommended on PHP 7.4+, MySQL 5.7+/MariaDB 10.3+, and newer WordPress versions. The core diagnostic approach and methodology remain applicable.