VS Load Test - Hierarchy of test metrics: Request/Page/Transaction/Test counters

When doing performance testing, one of the main metrics used to evaluate how the system is doing is throughput, throughput is the amount of traffic per time that the system is accepting. As throughput goes up, the system resource utilization also goes up, as well as the response times, at least at first. In Visual Studio throughput can be measured at a few different levels, and depending on what you are looking for and you unique system and test harness you may be using: passed tests per second, requests per second, transactions per second, etc.

Let's start by defining the 4 counters used by Visual Studio to measure traffic:

Test: Visual studio measures the elapsed time of one Webtest iteration, from start to finish, including everything inside. It includes  think time (if enabled) and any processing time from Plugins (although this is sometimes negligible).

Transaction: Transactions are used defined, they should be used to group pages and requests into a logical group that is useful for result analysis. I normally use this to group all pages and requests that are part of a business step, for example, the "Submit Login information", my transaction would include everything that got recorded from the Submit Login until the browser completes loading all resources.

Page: The page counter measures the time it takes to load all resources (including items not explicitly listed on the webtest) for a Page. For example a default.html, may include other content that gets downloaded behind the scenes such as CSS, images, Java Scripts, etc.

Request: Requests are individual request made during a webtest down to the lowest level, it includes CSS, png, jpg, gif, manifests, Java Scripts, etc.

 

You may already have guesses, but the hierarchy for these metrics normally goes like this: a test (webtest) should normally have several transactions in it (transactions are used defined, so a test could have 0 transactions, which is not a good practice), each transaction should have at least 1 page call, and inside each page call there should be one or multiple http requests. This graph may help visualizing it: