How To: Debug WordPress with Query Monitor

What is Query Monitor?

Query Monitor is a plugin developed by one of the core contributors of WordPress, John Blackbourn. It is branded as a debugging tool for developers, and is widely used in the WordPress community. In short, it watches every WordPress transaction happening on the site when the current page is requested, to provide detailed analytics.

Why use Query Monitor?

There are a few specific scenarios in which Query Monitor is useful:

• Your site has a high TTFB (Time to First Byte) on uncached views to the page, and you’ve narrowed the issue down to slow queries. Queries are used to construct pages from PHP and WordPress when requested, so if they are unoptimized, they can easily lead to high TTFB.
• If queries are not being run when they should be, or if queries are returning incorrect results
• You are experiencing wp-admin area slowness and turning off Object Caching helps the speed. Since Object Caching will cache repeated query results and transients, this helps narrow down the issue to the queries the pages are running.

When using Query Monitor, the most important parts to focus on will be the total execution time of the queries, how many/which ones are served from cache, and which queries are taking the longest amount of time. When Query Monitor is active, it is an option in your WordPress Admin bar. If you click the options from this menu, it will scroll to the bottom of the page. Here you will see the full Query Monitor analysis.

What else can it do?

Query Monitor not only monitors the queries running from your site! It also checks:

• Which “caller” or function/hook is calling the query
• Gives a trace of which piece of code is calling it
• Gives a trace of any dependencies and conditionals being met by queries executed on the page
• Provides a breakdown of how much time it took for all queries to run
• How much Memory the page used in being generated
• The percentage of queries that were served from Object Cache.
• Which scripts are being run, their position on the page and a trace of which files the scripts are triggered from
• It also detects any PHP Warnings or Errors generated by the page
• Gives a report of the server the site is running on:
  • PHP version
  • Max_execution_time
  • Memory allotted to WordPress
  • Database being used
  • query_cache_limit (Object Cache)
  • Debugging information

All this data can be extremely helpful to developers looking to optimize their sites!

On top of the extra data it generates, it can be run on the front end without being logged in by setting a specific cookie (this setting is available at the bottom of the report when logged in initially). So in addition to debugging, this information can also help developers understand what conditionals and hooks their own code should hook into, to function properly.

Caveats

There are also some caveats to understand when using Query Monitor on some hosts and environments. These are some common errors to look out for:

• Query cache: Query Monitor is checking to see if “mysql_query_cache” is being used. WP Engine and some other hosts use a separate service for query caching, called Object Cache. As a result, some of the information may lead you to believe that queries are not being cached, when in fact they are (as long as Object Cache is enabled). The cached percentage at the top of the report will still report this accurately.
• Query Monitor was unable to symlink its db.php file into place: This error means that the Query Monitor is trying to symlink its own db.php file within its plugin directory to wp-content/db.php. Many webhosts will already have the db.php file in the wp-content directory, so often times this is a red herring.
• Query Monitor on clustered environments: On clusters and redundant environments with multiple web servers, the requests that Query Monitor is tracking are run from the web servers of the cluster. However, in these environments MySQL is usually only run in READ only mode there. MySQL passes all write operations to the database master server. This conflicts with the code of Query Monitor, so it doesn’t work properly on these environments. In these cases, making a copy of your site to a single-server environment to test is best practice.