Page and transaction timings are only recorded once a page finishes, and a page that hangs may never report at all. The Waiting Users metric counts virtual users stuck on a response right now, so it rises at the moment a bottleneck starts instead of minutes later. WPLoadTester developed it as an early-warning indicator and reports it at every level of the test.
Waiting Users reports how many virtual users are currently waiting for the server to respond to one or more requests. It is available at every level of the results: the entire test, an individual test case, a web page, and a single transaction. Our test engineers built it to find which pages and transactions were holding up the most users.
A page or transaction duration is only recorded once that page completes. If a page is slow, its measurement arrives late. If a page hangs, the measurement may never arrive at all. Waiting Users does not wait for completion. It increments the instant a request goes outstanding, so it climbs at the same time the server starts falling behind.
In this test the rush of new users during ramp-up is not handled gracefully. Waiting Users rises quickly. Average Page Duration rises much later, only once the slow pages finally complete. Reading Average Page Duration alone, the problem looks like it began minutes after it actually did.
Average Wait Time is the companion metric. It captures how long, on average, each currently-waiting user has been waiting. Like Waiting Users, it tends to move before the overall averages do, which makes it a second leading indicator of a capacity limit.
Because Average Wait Time excludes completed requests, it is good at catching the case where most requests are served quickly but a few are much slower. Read alongside Waiting Users, it tells you which kind of trouble you are in:
Waiting Users and Average Wait Time sit on top of the metrics WPLoadTester records for every page and every transaction in the test. Every timing metric is reported as a minimum, maximum, average, and standard deviation, so you see the spread of the result, not just the middle of it.
Every one of these is available at the test, test case, page, and transaction level, so a slowdown can be traced from the whole test down to the single transaction causing it. Because WPLoadTester records at the HTTP level, every transaction inside a page is measured separately. Modern pages make many requests to populate a single view, and the transaction-level timings show which of those requests is the slow one.
Every metric on this page is plotted in the WPLoadTester 7 Analytics Dashboard against the user level, so you can read Waiting Users and Average Wait Time against response-time degradation on the same axis and watch which one moves first.
Watch the bottleneck as it forms, not after.
Waiting Users and Average Wait Time ship in every WPLoadTester 7 install. Request the 7.0 beta to run a test and see the leading indicators move before the page timings do.
Comparing tiers? See the Free vs Pro split.