In a performance test script, a transaction refers to a group of requests which are sent to the server. A simple webpage may contain multiple requests which are associated with the components available on it. When a user does any action like hitting a button on the webpage then these requests (sync or async) are wrapped in one transaction and sent to the server to get the response. In simple performance testing terms, a transaction simulates a user action like Login, Search, Submit an order, Logout etc.
Example: Let’s consider a login page has 10 components encapsulated within a transaction named “Login” which sends 10 HTTP requests (associated with each component) then you can see 1 dot entry in the ‘Transactions per second’ graph whereas 10 dots entry in ‘Hits per second’ or ‘Requests per second’ graph.
The transactions per second graph or TPS graph shows the rate of transactions achieved during the test. With the help of the TPS graph, you come to know what is the transaction handling capacity of the server. The more TPS with the expected response time of the application the more transaction handling capacity of the system.
During live monitoring:
Another purpose of the Transactions per second (TPS) graph during the live test is to keep an eye on the transaction rate. The TPS rate should not breach the defined SLA, if so then you need to recalculate the pacing.
As per PTLC (Performance Test Life Cycle), the Transactions per second NFRs should be discussed and agreed upon during the NFR gathering phase. If the application is new then you should ask the expected TPS from the client or business analyst to measure the true performance of the application.
Term to represent the TPS graph in different tools:
- LoadRunner: Transactions per second Graph
- JMeter: Transactions per second Graph
- NeoLoad: NA
Transactions per second Graph axes represent:
- X-axis: It shows the elapsed time. The elapsed time may be relative time or actual time as per the graph’s setting. The X-axis of the graph also shows the complete duration of the test (without applying any filter).
- Y-axis: It represents the rate of transactions at a particular time.
How to read:
The TPS graph is very helpful during the live test. The graph shows the achieved TPS rate which can be compared with the defined SLA. The summary table may show min, max and average TPS. Based on the tool, there may be 2 types of TPS graphs available:
- Transactions per second
- Total Transactions per second
The TPS graph is a descriptive form of the Total TPS graph. The total Transactions per second graph (Figure 02) shows the overall TPS achieved during the test whereas the Transactions per second graph (Figure 01) shows the TPS rate of the individual transaction.
As mentioned above achieved TPS should be equal to the defined TPS if it is not then:
- Check response time graph: If transaction response time breached the response time NFR (or noted higher than expected) with constant pacing and think time then this will impact the TPS rate. To resolve such a problem you have to use dynamic pacing logic, so that response time can be adjusted with iteration delay.
- Re-calculate Pacing and Think time: If there is no issue observed in the response time then you need to re-calculate pacing and think time. (Constant Pacing Calculator and Think Time Calculator)
- Increase number of users: If you have already given real-time pacing/think time and response time is also meeting your requirement; still achieving less TPS then you have to increase the number of users regardless user count is not given in the NFR.
Merging of TPS Graph with others
- With no. of users graph: You can merge transactions per second graph with running Vuser graph to understand the downfall in TPS rate. One of the reasons could be the exiting of the users from the test.
- With Response Time graph: Merge the Average transaction response time graph with the TPS graph to see the effect of the number of transactions upon the performance of the transaction. An 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 reduction in the TPS graph.
- With Throughput Graph: Ideally, the transactions per second graph should be followed by a throughput graph. If it is not the case then you need to check the error or network latency graph. Before concluding the result, consult other graphs too.
Remember: Before making any conclusion, you should properly investigate the root cause of the performance bug by referring to all the related analysis graphs.
You may be interested: