WordPress Performance & Debugging

WordOps General Operations

We use WordOps to manage WordPress/WooCommerce instances. See our WordOps handbook for general operations.

Debugging

The first thing you should you is to enable WP_DEBUG (disabled by default), and also configure sub-options WP_DEBUG_LOG and WP_DEBUG_DISPLAY so you have better control over these options separately. Edit wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );

Reference: Debugging in WordPress

Debugging Plugins

There are many debugging plugins for WordPress that show more information about the internals, either for a specific component or in general. Here are some examples:

Performance

WordOps Dashboard (Netdata)

First of all we can use WordOps Dashboard (based on Netdata) to check general server metrics. This is useful for knowing the general health/responsiveness of system, even without knowing yet the cause of specific issues.

Install: (should have been automatically installed)

sudo -E wo stack install --dashboard --netdata

To access WordOps dashboard, go to https://server-cname.domain.tld:22222/ . If you lose WordOps Dashboard username & password, reset it using:

sudo -E wo secure --auth

Use a custom username and an auto-generated strong password.

If you can’t access WordOps dashboard, make sure:

Amazon Lightsail allows port 22222
You’ve created a WordOps site (without WordPress) with LetsEncrypt SSL certificate:

export CF_Key=...
export CF_Email=...
sudo -E wo site create server-cname.domain.tld -le --dns=dns_cf

Ensure /var/www/22222/conf/nginx/ssl.conf refers to the correct SSL certificate, not for other site

Diagnosing Slow Applications / Too Much Resource Consumption

In Netdata, go to Applications. You’ll see CPU usage, disk usage, etc. per application. So now you know the culprit at least on a server level. After you’ve identified the application, you can proceed to diagnose on application level.

Engineering