LoadRunner – Average Transaction Response Time Graph

LoadRunner - Average Transaction Response Time Graph

Purpose: 

In LoadRunner, Average Response Time Graph is used to plot the graph for the response time of each transaction during the performance test. Now, here is a question what is response time, so “Transaction Response time” refers to the time that elapses between when a user does an action on the web page like press ‘Order’ button till he gets the order number from the server. In the simple words the time between when the first byte (of request) sent to the server till the last byte (of response) received from the server. This response time also includes network delay time. To get more information about response time, refer to the article “What does come under a simple”Response Time”?”.

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 a complete duration of your test without applying any filter.
  • Y-axis: It shows the average of transaction response time (in seconds)
LoadRunner - Average Transaction Response Time Graph
Figure 01: LoadRunner – Average Transaction Response Time Graph

How to read Average Transaction Response Time Graph?

You can see multi-colour lines in the response time graph. These lines show the response time of each individual transaction along the time. Peaks in the graph indicate that a delay in getting the response. This delay may be due to user load, server fault or network issue which need to be investigated by referring Latency, Error per second, Throughput or Running Vusers Graph. You can also apply a filter to look into individual transaction performance. A flat line of transaction response time within SLA during steady-state shows the application’s good performance, on the other hand, more fluctuation or deviation means performance may vary under actual load condition in the live environment.

The bottom table has some columns like line colour, scale, measurement (i.e. name of transactions) minimum, maximum, average, standard deviation etc. The numbers in the table help to validate the defined NFRs for a particular transaction.

Example:

As stated earlier, LoadRunner uses ‘Average Transaction Response Time’ graph to represent the average time taken to perform transactions during each second of the test. If you run a test with 5 Virtual Users and 1 transaction (say Login) and get the response time:

1st Vuser has 1 sec Transaction Response Time
2nd……………..2 secs…………………………………….
3rd………………3 secs…………………………………….
4th………………4 secs……………………………………..
5th………………5 secs……………………………………..

So, the average transaction response time of Login transaction would be (1+2+3+4+5)/5=3 secs.

Merging of ‘Average Transaction Response Time Graph’ with other graphs:

  1. With Running Vusers Graph: In LoadRunner Analysis tool, you can correlate Average Transaction Response Time graph with Running Vuser graph to see how the number of Running Vusers affects the transaction response time. Normally, the Average Transaction Response Time of the transactions in the graph should have very less deviation. I won’t say average response time should be constant because that is an ideal condition. In some cases, average response time increases or decreases at the beginning or during the test then merge this graph with Running Vuser graph to understand the impact of user load on the server response time. Sometimes you can see a sudden drop in the average response time and when you merge with the Running Vuser graph then you come to know that some of the Vusers exited at the same time.
LoadRunner - Average Transaction Response Time Graph with Throughput Graph
Figure 02: Average Transaction Response Time Graph with Running Vusers Graph
  1. With Throughput graph: Average transaction response time graph can be overlaid with Throughput graph. You may find different patterns while analysing the throughput graph with average transaction response time graph which are:
    1. An Increase in Throughput along with Response time: This situation is possible when users are ramp-up.
    2. An Increase in Throughput when the Response time drops: This situation may occur when the system is recovered and started responding too fast.
    3. A Constant Throughput with the increase in Response time: The reason may be a network bandwidth issue or request queuing issue. If the network bandwidth is reached at its maximum limit then it causes a delay in transferring the data. Therefore throughput makes a flat line (max bandwidth) and response time makes top headed inclination.
    4. A decrease in Throughput with an increase in Response time: If you see in the graph, throughput decreases with the increase in response time then investigate at the server end.
Figure 03: Average Transaction Response Time Graph with Throughput Graph
  1. With Error Graph: Response time graph when overlaid with error/second graph then you can easily identify the exact time when the first error occurred as well as the time until the error lasts. You can also check whether response time increases after the first error appeared? Commonly, an increase in error % during ramp-up indicates error due to user load. If error identified during steady-state then this indicates queue pile-up at the server (a large number of unprocessed requests at server end). As I said, before making any conclusion you have to investigate properly by referring different analysis graphs as well as by merging them together.
Average Transaction Response Time Graph with Errors per second
Figure 04: Average Transaction Response Time Graph with Errors per second Graph

Average Transaction Response Time graph is an important graph that can be directly compared with the defined NFRs; provided that proper response time NFRs are available. So, definitely use this graph while analysing the test results.


Leave a Reply

Your email address will not be published. Required fields are marked *