Understanding the relationship between hits per second & throughput in performance testing

First let's see what Hits per second & Throughput means.

Hits per second - Number of request hits the web server per second.

Throughput - Amount of data in bytes (Response) that the Vusers received from the server in a second. Measured in bytes/second.

In Analyzer we have an option to merge the graphs, using that we can merge the Hits per Second & Throughput graph to understand how the application is performing.

Below are the possible scenarios.

1. When Throughput graph is plotted higher than the Hits per second graph then  the application is performing great, which means the servers are processing the requests at a rate greater than the requests are reaching the server.

2. When both the graphs are parallel or overlapping with each other then the application is performing good, which means the servers are processing the requests at a same rate the requests are reaching the server. (See the below Image).

3. When Throughput graph is plotted lower than the Hits per second graph then the application is having issues, which means the servers are processing the requests at a rate lower than the requests are reaching the server.

Understanding the relationship between the Throughput & Response Time in performance testing

First let's see what Throughput & Response Time mean.

Throughput - Amount of data in bytes (Response) that the Vusers received from the server in a second. Measured in bytes/second.

Response Time - It is the total time it takes from when a user makes a request until they receive a response. Measured in seconds.

So it is evident that both are related with the response of the application.

Lets see how we can extrapolate the performance of the application from the Analysis Summary
(Under Statistics Summary) using Throughput & Response Time.

Basically you need to compare the Total Throughput (Bytes) & Response Time between the runs to identify how well the application is performing.

Comparison between the runs:

• If throughput is increasing and response time is consistent or decreasing then there are no issues, the application is performing good.
• If throughput is increasing and response time is increasing then there is issue, the application is not able to process the growing huge bytes of data. So the requests would have been queued as a result response time increased due to the wait time.
• If throughput is decreasing and response time is increasing then there is a serious issue, the application is not even able to process a minimum load. Which should be looked upon immediately.

So the conclusion is, If we are able to download large bytes of data in less response time then your application is performing good.

More about Blocks in Run Time Settings (RTS)

If at all we would like to iterate a set of Actions in the Run Logic we can use Blocks.

Below is the flow for an e-commerce application.

Login --> Search Books --> Search Electronics --> Place Order --> Logout

• Our criteria is that each user should repeat the Search Actions 10 times. 
• So we have grouped Search Books & Search Electronics Action under Block. (Just rt.click on Run and Select Add Block then rt.click on the Block and Select the Actions)
• On the top right corner we can see group properties in which I have mentioned the number of Iterations for the Block as 10. So each user will execute the Block 10 times.
• In the Run Logic I have chosen Sequential, So Actions will be executed one after the other Sequentially. 
• Instead we can also chose Random. So that Actions will be executed Randomly.
• In the above image we can see that, number of User iterations is 5 for the whole Run Logic, which means each user will execute the Block 10 times and on the whole Blocks will be executed to a total of 50 times.

Note:

• When we are bringing all the Actions under block and if we are going to use the Block iterations instead of the Run Logic iterations, then please note that Pacing is not applicable to the Blocks. 
• So you have to give the pacing value as think time at the end of the last Action in the Block.
• Say for example we are moving Login and Logout to vuser init & vuser end respectively and rest all actions as a block in the Run section then pacing should be added as think time function at the end of Place Order Action.