Posted on

New in Query Monitor 3.1: Profiling and Logging

Query Monitor 3.0 quietly introduced a feature which allows developers to profile the running time and memory usage of their code. Query Monitor 3.1 has just been released which adds a PSR-3 compatible logger which allows developers to log debugging messages to Query Monitor.

Some of the other changes in QM 3.1 include:

  • Lots of accessibility improvements.
  • Switch to system default fonts to match the WordPress admin area.
  • UI improvements for mobile/touch/narrow devices.
  • Various improvements to the layout of the Scripts and Styles panels.
  • Prevent the “overscroll” behaviour that causes the main page to scroll when scrolling to the end of a panel.
  • Add a settings panel with information about all of the available configuration constants.

Let’s take a look at profiling and logging in detail.

Profiling

Basic profiling can be performed and displayed in the Timings panel in Query Monitor using actions in your code:

// Start the 'foo' timer:
do_action( 'qm/start', 'foo' );

// Run some code
my_potentially_slow_function();

// Stop the 'foo' timer:
do_action( 'qm/stop', 'foo' );

The time taken and approximate memory usage used between the qm/start and qm/stop actions for the given function name will be recorded and shown in the Timings panel. Timers can be nested, although be aware that this reduces the accuracy of the memory usage calculations.

Timers can also make use of laps with the qm/lap action:

// Start the 'bar' timer:
do_action( 'qm/start', 'bar' );

// Iterate over some data:
foreach ( range( 1, 10 ) as $i ) {
    my_potentially_slow_function( $i );
    do_action( 'qm/lap', 'bar' );
}

// Stop the 'bar' timer:
do_action( 'qm/stop', 'bar' );

Here’s what the Timing panel looks like:

Query Monitor's Timing Panel

Note that the times and memory usage displayed in the Timings panel should be treated as approximations, because they are recorded at the PHP level and can be skewed by your environment and by other code. If you require highly accurate timings, you’ll need to use a low level profiling tool such as XHProf.

Logging

Debugging messages can be sent to the Logs panel in Query Monitor using actions in your code:

do_action( 'qm/debug', 'This happened!' );

The logger is PSR-3 compatible, so you can use any of the following actions which correspond to PSR-3 log levels:

  • qm/emergency
  • qm/alert
  • qm/critical
  • qm/error
  • qm/warning
  • qm/notice
  • qm/info
  • qm/debug

A log level of warning or higher will trigger a notification in Query Monitor’s admin toolbar.

Here’s what the Logs panel looks like:

Query Monitor's Logging Panel

Contextual interpolation can be used via the curly brace syntax:

do_action( 'qm/warning', 'Unexpected value of {foo} encountered', [
    'foo' => $foo,
] );

A WP_Error or Exception object can be passed directly into the logger:

if ( is_wp_error( $response ) ) {
    do_action( 'qm/error', $response );
}
try {
    // your code
} catch ( Exception $e ) {
    do_action( 'qm/error', $e );
}

Finally, the static logging methods on the QM class can be used instead of calling do_action():

QM::error( 'Everything is broken' );

I hope you find these two new features useful. As always, feature requests and bug reports can be reported on Query Monitor’s GitHub repo.

Leave a Reply

Your email address will not be published. Required fields are marked *