Skip Navigation

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.

Install and activate the Debug Objects plugin

We will use the Debug Objects plugin to see and understand the database queries needed to render your site. Debug Objects 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 plugin, go to the WordPress Dashboard and choose Plugins from the left menu, and then Add new. In the search field, type “debug objects” and press the enter key.

On the search results screen, click the Install now button:

Installing Debug Objects plugin
Installing Debug Objects plugin

After the installation is complete, activate the plugin.

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

Disable Xdebug

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

Configure Debug Objects to analyze SQL queries

First, please add this line to your wp-config.php file (this file is located in the main directory where your WordPress is installed):

define( 'SAVEQUERIES', TRUE );

Now, go to Tools -> Debug Objects and disable all of the options except DB Query:

Configure Debug Objects
Configure Debug Objects

Scroll down to the bottom of this screen and click the Save button.

Check the debug output

After the plugin has been activated and configured correctly, we can start debugging. While logged in as the WordPress administrator, visit any page, where you feel that your site is running too slowly (if this is the case for many pages, choose one that appears to be the slowest) and click on the Objects link in the top admin menu bar:

Debug Objects link ready for you
Debug Objects link ready for you

You will see three tabs with the debug information:

Debug Objects output in three tabs
Debug Objects output in three tabs

How to read and understand the debug output

In these three tables, you will see plenty of data but only part of it is important for us and relevant to the WPML plugin. Generally speaking, we are 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

Go to the first tab, called DB Queries, and search for the slowest queries. The Debug Objects plugin helps us to do this by highlighting queries that require more than 0.5 ms with an orange border:

Slow queries
Slow queries

Under the query string, you can see the name of the function that performed the query. However, this might be misleading because this tab only shows the last function from the full execution stack and we do not know if this originates from the WordPress core or from one of plugins (or which plugin).

Check whether the query came from the WPML plugin

Copy the slow query (ctrl+C) and select the second tab, called Plugin DB queries. You can see a few tables with queries, which are organized according to the plugins names and the plugins files through which the queries passed. If the WPML plugin participated in the execution of this query, it should be listed in the relevant table.

Press ctrl+F on your keyboard and then press ctrl+V to paste the copied query.

This will start a search for every occurrence of the selected query in this table. You will probably see more than one result. To jump between them, press the F3 key.

For every search result, check whether it is in the table located under one of the WPML plugins. If this is true, write down:

  • the plugin name
  • the file where the query was executed
  • the number of the line in this file (first column in the table)
Query details
Query details

Common queries from WPML and other plugins, and themes

Some of the queries pass through other plugins and/or themes as well as the WPML plugin. For example, WPML’s String Translation provides translation services for strings located in WordPress core, the theme and all other plugins. If you see the String Translation plugin staring in the list of DB queries, it means that WPML needs to translate many different strings in your site.

In this case, the query that you found slow will occur in the Plugin DB queries tab in the table under our plugin name, but also in the next tables related to other plugins, or in the third tab: WP Content DB queries. Please check this before you report a slow query via our forum. If you find the same query in the third tab, please write down the name of the file from the third tab. We will know if a specific theme is involved in running this slow query and the identity of the theme.

Reporting your results via 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 the following in your report:

  • The query that is slow and how long it takes to execute.
  • Where/whether you can find this query in the 2nd tab of debug log. Whether it is located in the WPML plugin and, if this is the case, the files that are involved, and their line numbers.
  • Where/whether you can find this query in the 3rd tab, as well as the file name and the line number.

Please copy the content of every tab 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. Open the first tab in the Debug Objects results
  3. Select the contents of this tab. Be sure to include everything from the ‘queries’, including the ‘errors’ section and the entire list of queries.

    Select all queries
    Select all queries

  4. Copy (ctrl+C) your selection
  5. Go to and paste (ctrl+V) your selection into the text area, and then press the Submit button.

    Paste into Pastebin
    Paste into Pastebin

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

    Copy Pastebin URL
    Copy Pastebin URL

  7. Paste the URL from Pastebin into the support thread.
  8. Repeat steps 2–6 for the contents of the other two tabs.

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 to work around it (and eventually improve 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 way to make sure that it’s off is to look at the phpinfo() output.

Xdebug showing in phpinfo output
Xdebug showing in phpinfo output (bad for performance benchmarking)

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

Remove, not add the above line!

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

phpinfo when Xdebug is not running (good for performance benchmarking)
phpinfo when Xdebug is not running (good for performance benchmarking)

As soon as this does not contain any reference to Xdebug it’s turned off for sure.
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.

Need help?