What is ‘Transactions per second’?
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 transaction can have multiple requests and encapsulates requests into a group e.g. a login operation which involves 5 HTTP requests can be group together into a single transaction. When you compare the graph of such scenario then there are five dots in the ‘Hits per second’ a graph against one dot in ‘Transaction per second’ graph.
Purpose:
The main purpose of Transactions per second (TPS) graph during the test is to keep eyes on transaction rate. If you have TPS SLA then you can control TPS rate by setting think time and pacing in the test script.
TPS exceeds SLA indicates that test script is making more hits on the server and resulting extra burden; on the other hand, if TPS SLA is unachievable then the test could not be considered pass in performance testing. Therefore make sure test script should have the proper pacing and think time calculation. You can calculate pacing using below link
Transactions per second graph also show passed and failed transactions count. Using ‘Total transactions per second‘ graph you can get the total number of transactions that passed, the total number of transactions that failed and the total number of transactions that were stopped, for each second of test run whereas ‘Transactions per second‘ graph displays passed, failed and stopped count of the individual transaction for each second of the test run.
LoadRunner Transaction Graphs:
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 graph’s setting. This also shows the complete duration of your test.
Y-axis: Number of transactions in test
How to read:
This graph is very helpful for the live monitoring of the test. The graph line shows achieved TPS rate to compare with your test SLA. The summary table shows the count of passed, failed and stopped transaction. In case TPS is unachievable then:
- Check response time graph: If response time is SLA breached (or noted high then expected) and you have given constant pacing or think time then this will impact TPS rate. To resolve such problem you can use dynamic pacing logic.
- Re-calculate Pacing and Think time: If no issue with response time then you need to re-calculate pacing and think time. Use dynamic pacing for a more accurate result.
- Increase number of users: Already you have given real-time pacing/think time and response time also meets your requirement. Still, TPS is not matching then you can increase the number of users regardless No. of users are not given in your SLA.
Merge with other graphs:
- With Running Vusers graph: You can merge transactions per second graph with Running Vuser graph to understand if any downfall in TPS rate due to stop/exit of the user.
- With Response Time: Average transaction response time graph can be correlated with Transactions per second graph to see the effect of the number of transactions upon the transaction performance time. Increase in response time impacts transactions per second inversely. Due to high response time (with constant pacing and think time setting) you will get a declination in transactions per second.
- With Throughput: Ideally, transactions per second graph should be followed by the throughput graph. If it is not the case then you need to check error or network latency graph.
