It’s a plugin that measures the performance of other plugins. Well, at least in theory. After several days of intermittent and furious development the plugin is more of a glorified hack, or rather an amalgam of hacks, that provides a myriad of details and slightly-inaccurate summaries about the inner workings of WordPress and its plugins. This is probably the closest thing to a real profiler that you can get without installing additional webserver modules (which wouldn’t be an option for 99% of WordPress users anyway).
- Tells you how much time it takes to load up each particular plugin you have active.
- Reports how long it takes to execute WP hooks – also known as actions and filters. Most plugins commonly use hooks to implement the majority of their features.
- Reports SQL query performance (per plugin and per function).
- Displays a neatly formatted and only slightly confusing report containing all of the abovementioned info at the bottom of each of your pages (by default only administrators can see the reports).
This is not a normal plugin. It will interfere with the inner workings of WordPress, notably anything AJAX-related. It will require core file modification (automatic where allowed by file permissions). It will make scary noises in the bushes when you go outside at night.
Do not leave this plugin active longer than necessary. Use at your own risk. You have been warned.
Download & Installation
- PHP 5 >= 5.0.0
- WordPress 2.6.0 – 2.6.2
Download : plugin-profiler.zip (72 Kb)
Install it like any other plugin – upload and activate. Then go to Settings -> Plugin Profiler and follow the instructions on that page to install the patches (make backups first). Finally, select the “Advanced” output format, load any page from your blog and scroll down to the bottom. You should see the performance report there.
Making Sense of the Reports
The reports this plugin creates are pretty self-explanatory, except the bits that are not. I will explain the basics and point out some non-obvious details, but I won’t attempt to describe each row of the output – that would take an article five times as long.
First, the plugin profiler always displays time in seconds, and usually to an excessive precision. Most numbers you will see on the reports show how much time was spent doing something. Other numbers that look like xNNN show how many times something was done. For example, if you switch to the “Queries” view and see a line that says something like “[WP Core] x11 0.0258664”, it means that the component “WP Core” – i.e. WordPress itself, as opposed to a plugin – run 11 SQL queries to generate the current page, and all those queries took about 0.026 seconds to run in total.
Items in the report are always sorted by total execution time, in descending order. This makes it easy to find slow plugins – just examine the top of the list.
As for non-obvious details, you might notice that sometimes the reported times don’t add up. In particular, this is true for the short summary table at the beginning of the report, which will always display a final page generation time higher than you would get if you added up the query/hook/etc execution times. This is because the plugin can’t track everything – things like file access, HTTP requests, and miscellaneous overhead won’t show up in the reports but will still add to the total. There’s no easy way to rectify this, but the information that the plugin can gather is still useful – it’s just not complete.
Another thing to note is that the total execution time for each plugin (in the “Components” view) is not accurate. There are many reasons for this – some very complex – but in short, the displayed values should be treated as useful estimates, not definitive results. However, all the additional info provided for each plugin (the number of queries, load time, etc) is accurate to the best of my knowledge.
Oh, and don’t trust readme.txt. The lying bastard.
I made this plugin because I’ve long since wished for a way to find the bottlenecks in my WordPress install. It just seems slow… too slow for a
moderately less somewhat popular blog running on a VPS. I wouldn’t say the plugin solved the problem, but it certainly gave me some interesting insights. For example, I found that in my case SQL queries represent an insignificant portion of the total page generation time. Loading and executing PHP files takes much longer. And there’s still a sizable chunk of the total that’s unaccounted for. Interesting.
In unrelated news, my new quad core CPU is running at 45 C when idle. HDD’s are at 50 C with little to no activity. Makes me a bit uncomfortable. Some drilling may be in order.Related posts :