When it comes to performance debugging, there are a wide variety of tools available. The last years, I searched for one that is actually easily usable and provides easy access in identifying bottlenecks.

There are some that are specific to WordPress, e.g. as plugins, some allow general performance debugging via PHP and some require a PHP extension to be loaded. I’ll cover all of these types in the following article.

The goal

My goal was to actually identify parts of my code that can be made faster. The main method would be by looking into a request and identifying function calls that take notable longer than the rest, either by just taking long time or by running way more often than expected.

A second goal was to find something that can also be used in production with as little overhead as possible, while still getting performance metrics from real world requests and not only within a (local) test setup.

Disclaimer: Even if the solutions I present below won’t fit my goals, that by far doesn’t mean that they’re bad as a whole.

Query Monitor

The first I tried was the plugin Query Monitor. It already covers some basic metrics and allow nice insights about the current request, with specific data around WordPress. It can detect slow or duplicate SQL queries pretty decent and map them to the corresponding code. It can also be used to manually profile parts of your code, but only after it is loaded. So running it early is not possible and also within WordPress core functions, it may not work properly.

For my goals, I couldn’t get it working properly (and especially automatically, since I would need to profile every function manually).

Code Profiler

Code Profiler is another plugin, which is explicitly marketed as “Performance Profiling and Debugging Made Easy”, so I had high hopes. In its free version, it lacks the ability to trace single methods and functions, but it is part of the Pro version for 89 $ per year, or 399 $ lifetime.

Technically, the Pro version does fulfil my requirements stated in the goal, but I had three issues with it:

  1. In my local testing, the numbers were very fluctuating. There was always a different plugin that took longer than expected. Disabling it had not much of a difference on the next request, though.
  2. It needs to be triggered manually, so getting real life data wouldn’t be possible the way I want to: from the actual user, not from me trying to replicate the exact same behavior.
  3. It’s based on using so called “ticks”, which it injects into every file before it’s being executed. Not only does this alter the actual files dynamically, which takes time, using it would meant to use a debugging function inside of production – and making the requests slower.

Xdebug

As its name already suggests, Xdebug is used as debugging tool – and should never be used in production. And even though it immediately disqualifies itself at this point, I still want to note it here for its performance debugging capabilities. It has a performance profiler builtin, that creates a cachegrind file for a profiled request (which needs to be triggered manually), which can then be inspected via tools like KCachegrind.

However, this data is not easily interpretable and sometimes confusing. So it requires a deep dive into how cachegrind files collect data and what data they actually contain and display.

To be able to run, you need to load a PHP extension and it requires many resources.

QCacheGrind output of a request with all executed functions in a sidebar left and its information on the right
QCacheGrind requires deep understanding in their data collection methods

XHProf

XHProf runs similar to Xdebug in this regard. While I bet it is technically very different, the output itself is similar (confusing). And it is also loaded via PHP extension and triggered manually. So pretty much the same reasons for me not to use it for production.

Summary of a request with request timings, calls, CPU and memory usage for each function in a table
Interpreting the collected data of XHProf is up to the user

Sentry performance tracing

Since we already use Sentry as error reporting tool, the decision was obvious to check out its profiling capabilities. There is a Sentry WordPress plugin, which also supports profiling. But unfortunately, they cannot be very precise. Builtin, they can only handle database, HTTP, transients, plugins and themes as a whole, which means that there is only an overall metric for all plugins, everything the theme does or similar.

That way, you can only get a rough overview of how much each part is contributing to the request duration, but no detailed output regarding particular parts of the executed code.

Traces in Sentry of a request with a single HTTP request (855.83ms), split in app.bootstrap (326.88ms) with plugins.setup (62.04ms), theme.setup (8.16ms) and some cache requests, and in wp.handle (528.89ms) with some cache requests
Very few insights about the actual executed code in Sentry

Tideways

Also coming with an own PHP extension, Tideways is a paid service to check for performance issues. It’s tracing looks similar to Sentry, but it is way more detailed and even allows deep inspections of every function call (if triggered). It also comes with a Chrome extension to allow triggering specific requests right from there, without the hassle of “how do I get my testing parameter to this specific Ajax request?”.

Timeline of a request with multiple bars representing the taken time of single code parts
A clean overview of a request in Tideways

In the timeline, you can hover over each bar individually and get detailed information about what currently was active. For the light turquoise ones, these are the most interesting, as they are particular functions within WordPress, especially plugins.

The biggest downside is that it’s a paid service and it seems that you cannot self-host it (at least I didn’t find any information regarding that), but for me, it’s worth the much more detailed, fine-grained and way more understandable format it presents the data. You can test it for free for 14 days without adding payment data

Also, the team around Tideways is highly interested in feedback and you can write with them about anything you notice or if you struggle with something. And yes, I noticed that WordPress is written wrong in the traces (reminds me of feedback I still need to give).

Conclusion

In the end, I’ll go with Tideways, since it’s just the best solution for me. It can detect slow code by itself and presents it in a ways that can be easily worked with. And it is explicitly designed to be used in production, too.

I would have loved to find something like this as a free open source tool, but unfortunately, the existing solutions are not that accessible or don’t fit my goals.

2 comments

  1. @epiphyt_en Have you also checked out https://github.com/NoiseByNorthwest/php-spx? We have been using it quite a lot and it‘s awesome.

Reposts

Leave a Reply

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

To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn more about webmentions)