What is ‘Hits per second’ graph in LoadRunner?
‘Hits per second’ refers to the number of HTTP requests sent by the user(s) to the Web server in a second. In terms of performance testing, there is a major difference in Transactions per second and Hits per second. A single transaction can create multiple hits on the server. A transaction is nothing but a group of requests in web test terminology. A LoadRunner script of a web-based application has some transaction and these transactions encapsulate requests into a group e.g. a login operation which involves 5 HTTP requests can be group together into a single transaction, so when you read a ‘Transactions per second’ graph and there is only 1 dot appeared then you can see 5 dots in ‘Hits per second’ graph.
Many testers consider the definition of ‘Throughput’ as ‘the number of requests per second’ and hence they refer throughput as the total number of hits in a test. As per Microfocus LoadRunner ‘Throughput’ is the amount of data from the server to the client and ‘Hits’ or ‘Requests’ is a number of HTTP calls made by the client on the server. I follow the later definition.
Purpose:
The main purpose of Hits per second graph during the test is to keep eyes on the number of requests sent by LG (virtual user) to the server. After the test, you can compare the rate of hits with throughput and investigate if any mismatch. Ideally, the throughput graph should follow hits per second graph. If it is not the case or it follows reverse (or flat) trend then there could be the bottleneck which needs to be resolved.
Graph Axes Representation:
- X-axis: This graph having elapsed time on X-axis. The elapsed time may be relative time or actual time as per the graph’s setting. This also shows the complete duration of your test (without filter)
- Y-axis: Number of requests (hits)
How to read ‘Hits per second’ graph:
This graph is very helpful during the live test. The graph line shows how many HTTP requests are being sent to the server in the per-second interval. Once users are in the steady-state then hits per second graph should have a range bound fluctuation means there should be less deviation. If you see any drop in the hits per second rate then you need to check the number of running users and response time graph to understand the reason of drop.
Merging of ‘Hits per second’ graph with other graphs:
- With Running Vusers graph: You can merge hits per second graph with Running Vuser graph to understand if any downfall in hits due to stop/exit of the Vuser.
- With Average Transaction Response Time Graph: Average transaction response time graph can be correlated with hits per second graph to see how the number of hits affects transaction performance. Increase in response time impacts hits per second inversely. Due to high response time (with constant pacing and think time setting) you will get the declination in hits per second graph.
- With Throughput Graph: As mentioned above if Hits are requests then the throughput is the response. Ideally, the hits per second graph should be followed by the throughput graph. If it is not the case then you need to check the error or network latency graph.
