Measuring the Performance Win
It is worth measuring what Scalability Pro actually does for your site, rather than trusting the impression that pages “feel faster”. A real number tells you whether an index or an option earned its place, shows you where the remaining slowness is, and gives you something concrete to show a client or a host. This article covers how to take those measurements and how to run a fair before and after test.
What to measure
There are three separate things worth measuring, and they improve for different reasons, so keep them apart.
The first is the front end: your shop page, product category pages, blog archives and any custom post type lists. The headline metric here is TTFB, the Time to First Byte, the time from the browser asking for the page to the server starting to send it back. It is almost entirely made up of the work WordPress and the database do to build the page. Alongside TTFB, note the number of database queries the page runs.
The second is wp-admin. The Posts and Products list screens, the status filters and the order screens are a big part of what Scalability Pro fixes, and they are never page cached, so the database improvement shows up directly. Measure these the same way, by TTFB and query count.
The third is imports. Here the useful numbers are throughput, in rows per second, and the total time for the whole import to finish. This is where Scalability Pro often makes the largest difference, and the one people most often forget to measure because the import runs in the background.
Measuring with Query Monitor
The plugin’s own recommendation is the free Query Monitor plugin, and it is the quickest way to get both numbers at once. Install it from Plugins > Add New and activate it, and it adds a panel to the WordPress admin bar on every page you load while logged in.
Query Monitor is the fastest way to read TTFB (page generation time) and query count side by side. Keep it installed while you measure, then deactivate it afterwards – it adds its own overhead to every logged-in page load.
Load one of your slow pages. Query Monitor shows the page generation time in the admin bar, which stands in for TTFB, together with the number of database queries and the total time spent in those queries. Click the admin bar entry to open the full panel for the detail behind those totals.
If a page is running a lot of queries, more than a hundred say, use Query Monitor’s “Queries by Component” view. It groups the queries by the plugin, theme or core component that fired them, so instead of scrolling through a thousand near-identical rows you can see which plugin is responsible for the bulk of them. That is usually enough to tell whether the problem is something Scalability Pro addresses or something coming from a filter or search plugin that needs a different tool.
As a rough guide, aim for under 300 queries, ideally under 100, and under 20 with a working object cache. A high count is a symptom rather than always a problem, so read it alongside the query time, not on its own.
Using the built-in Slow Query Log
Query Monitor tells you about the page you are looking at. To catch the slow queries across the whole site, including ones that only fire on pages you would not think to test, use the plugin’s own Slow Query Log, which lives on its own settings tab. It records any query that runs longer than a threshold you set, and for each one it captures the SQL and a stack trace showing which plugin or theme triggered it. That trace is the valuable part, because it names the culprit rather than just telling you a query was slow.
The Slow Query Log is a diagnostic tool, not an optimisation, and logging has its own cost, so switch it on to find your slow queries and switch it off again once you have them. The full method, including setting a sensible threshold and restricting the log to a single table, is covered in the Using the Slow Query Log article.
A fair before and after test
The point of a before and after test is that only one thing changes between the two measurements. If you build indexes and enable half a dozen options and re-measure, you learn that the site got faster but not what did it.
Changing several things at once and then measuring. Build the indexes, re-measure, and only then enable options one at a time. Otherwise a gain (or a regression) cannot be pinned to the change that caused it.
Take your baseline first. A clean baseline means measuring with the indexes removed: use Drop All Indexes on the Indexes tab before you measure. Note that deactivating the plugin also drops its indexes (and turns off everything else at the same time), so deactivation is not a clean way to isolate a single change. Load your chosen page a couple of times so any object cache is warm, then record the TTFB and query count.
Now change one thing. Build the indexes first, because they are usually the single biggest win and they change no behaviour. The Quick Start Guide walks through creating them: Indexes tab, Select All, Update Indexes. Once they have finished building, load the same page again, warm it the same way, and record the numbers. The difference is what the indexes bought you, and there is more on why they matter in the Custom Database Indexes article. After that you can enable options one at a time and re-measure if you want to attribute the gain from each.
Keep the test like for like. Measure the same page or admin screen, in the same logged-in or logged-out state, with caches warmed the same way each time. Comparing a cold first hit against a warm second one will flatter or spoil the result for reasons that have nothing to do with the plugin.
One caveat matters most on the front end. A page cache can hide the win entirely, because a cached hit never touches the database, so both the before and the after come back fast and identical. To see the database improvement Scalability Pro provides, measure uncached: use an admin screen, stay logged in so the cache is bypassed, or add a cache-busting query string to the URL.
If a front-end before and after both come back fast and near-identical, you are almost certainly measuring a cached hit. Add a unique query string (for example ?cachebust=123) to force a live database render, or measure a wp-admin screen, which is never page cached.
Measuring imports
For imports, pick one representative import and time the whole thing, then run the same import again after building the indexes and enabling the options on the Imports tab. Note the total time and, if WP All Import reports it, the rows per second, and run the two imports against comparable data so the comparison is fair.
If an import is slower than you expect and you want to see the queries behind it, Scalability Pro can run a single import batch through a normal wp-admin page so Query Monitor can see it, by appending spro_show_import_queries=yes to the processing URL. Imports normally run over ajax where Query Monitor cannot reach them, so this is the way to profile them. The Using the Slow Query Log article has the full walkthrough.
What good looks like
There is no universal target, because it depends on your data and your stack. A good result is a clear drop in TTFB on the pages and admin screens you actually use, a query count that has come down towards the guide figures above, and no slow queries left in the Slow Query Log at a sensible threshold. For imports, it is a shorter total time and a higher rows per second on the same job. If the front end still feels slow after all that but the numbers are healthy, the remaining cost is likely PHP rather than the database, which points at a different fix rather than more indexing.
Comments