How to Debug Performance Problems

Every plugin that you add to your WordPress site will add execution time and database queries. In this tutorial, we explain how to check where execution time comes from. With this information, you and WPML support team can find bottlenecks and improve your site’s performance.

Installing and Activating the Debug Bar plugin

We will use the Debug Bar plugin and the Debug Bar Sort Queries add-on to see and understand the database queries needed to render your site. Debug Bar will show a detailed breakdown of the queries which run on every page in the site. This output is only visible to you when you are logged in as an admin. Visitors will not see the debug information.

To install the Debug Bar plugin, go to Plugins → Add new. In the search field, type “debug bar” and press the enter key.

On the search results screen, locate the Debug Bar plugin and click the Install Now button:

After the installation is complete, activate the plugin.

Alternatively, you can download Debug Bar directly from the WordPress repository and upload it to the wp-content/plugins folder on your server. Then, activate it via the Plugins page in your WordPress admin.

The Debug Bar Sort Queries add-on is not on the WordPress.org repository, so you will need to install it manually. To do this, download the plugin. Then, go to Plugins → Add new and upload the plugin to your site. Remember to activate it.

Disabling Xdebug

If you don’t know what Xdebug is, feel free to skip this section. If you are using Xdebug, make sure to disable it before you start with performance testing. Xdebug will cause significant load on your server and alter the results. Learn how to disable Xdebug.

Configuring Debug Bar

Debug Bar has a couple of debugging options:

• • You can enable WP_DEBUG to identify problems in your code and track PHP Warnings and Notices
  • You can enable SAVEQUERIES to identify any performance issues on your site and to track and display MYSQL queries.

To enable these options, head to the main directory of your WordPress installation. In your wp-config.php file, you’ll see a line that says /* That’s all, stop editing! Happy blogging. */.

Right above that, add the following line of code:

define( 'WP_DEBUG', true );
define( 'SAVEQUERIES', true );

Checking the Debug Output

Once you have activated and configured the plugin, you can start debugging.
While logged in as the WordPress administrator, visit any page you feel is causing your site to run slowly. If you have multiple slow pages, choose the slowest one. Then, from the top admin bar click on Debug → Queries:

You will see a screen with the debug information for the post or page:

Reading and Understanding the Debug Output

The Queries screen shows plenty of data, but not all of it is relevant to WPML. Generally speaking, our Support team is interested in two things:

• Very slow queries – sometimes, much of the performance problem is a result of a few queries that take a long time to process
• Many repeating queries – other times, there are no very slow queries, but many fast queries that together take a long time to complete

Locating Slow Queries

At the top of the Queries screen, you can see the Total Query Time. The Debug Bar Sort Queries add-on lists the queries in order from the slowest to fastest execution time. You can find the execution time for each query on the far right-hand side:

A query with an execution time of a few milliseconds is acceptable. Generally speaking, we can say a query is slow when the execution time is in the 50-60 milliseconds range. However, please note that execution time is dependent on the server speed. The same query can be fast on one server, and slow on another.

To see which plugin or theme the query is coming from, take a look at the call stack in the second line of each query.

In the example below, we’ve marked a query coming from WPML:

For every query result, check whether any WPML plugins or add-ons are included in the call stack. If they are, write down:

• The SQL query
• The call stack in the next line of query
• The query execution time

Reporting Your Results via the WPML Technical Forum

When you have written down all of the data related to the slow query, please create a new ticket at our forum and explain your problem. Please include all the information listed in the bullet points above in your ticket.

Please copy all the content from the Query screen and share it with us using Pastebin.

To do this:

1. Go to WPML’s technical support forum and start a new thread. Describe the performance problem you’re seeing and where we can see it too.
2. Head to your affected page or post and then click on Debug → Queries in the top admin bar.
3. Select the contents of this screen. Be sure to include everything from the ‘queries’, including the execution order and the execution time for each query.
4. Copy (ctrl+C) your selection
5. Go to pastebin.com and paste (ctrl+V) your selection into the New Paste text area and then press the Create New Paste button.

6. Copy the URL from the address bar of your browser.

7. Paste the URL from Pastebin into the support thread.

Now, our supporters know which site you are referring to and which page loads slowly. They can see a full list of the queries running and can help you find the cause of the problem. If it’s in WPML, we’ll see how we can temporarily work around it and the improvements we need to make in an upcoming version. If it’s in the theme or other plugins, we’ll talk with the other authors and do our best to get everything running smoothly for you.

Appendix: Disabling Xdebug

Xdebug is a PHP extension that allows you to debug code problems. When used correctly, it will also help you analyze the source of performance issues.

When it runs, Xdebug adds considerable load to the server because it needs to capture what is happening in real time. For this reason, you should never have Xdebug running when you are doing performance benchmarks. If Xdebug is running while you measure performance, you will be getting completely wrong numbers. Most of the reported load will be due to Xdebug and not due to the code that you want to benchmark.

The correct way to debug performance issues with Xdebug is to measure without Xdebug, get the results and then find the source performance hog using Xdebug.

Xdebug may be running on your server even if you’re not checking its output. This often happens when people enable Xdebug for real debug work and leave it loaded, thinking that it’s inactive.

The best way to make sure that it’s off is to look at the phpinfo() output.

If you want to turn off Xdebug, do it by removing or out-commenting from either your php.ini file or your conf.d/xdebug.ini file:

zend_extension=xdebug.so

Remove, don’t add the above line!

This is how the phpinfo file should look like when Xdebug is not running:

As soon as this does not contain any reference to Xdebug, you can be sure it’s turned off.
Whether or not other sections of this phpinfo file contain references to Xdebug is not important, so long as it is not shown as a loaded extension at the top.