I was working on performance testing for a project not long ago that had different VUser types each with different load requirements. This meant that in one load test scenario, there were several user groups having unique transactional load characteristics (like desired TPM), not based on the whole scenario but by individual groups. At that time I created a simple spreadsheet to calculate the ramp-ups, pacing and actual load for each of the group and totals given the expected load and the number of virtual users. I recently got some time to improve it a little and am sharing it now.
So here's that table with some sample values:
VUser Group | Base Load (TPM) | Number of VU | Multiplier (Load Factor) | Expected Load (TPM) | Expected Ramp Up (seconds) | Actual Ramp Up (seconds) | VU Pacing (seconds) | Actual Load (TPM) |
| 1 | 30 | 100 | 1 | 30 | 2.00 | 2 | 200 | 30.00 |
| 2 | 34.2 | 14 | 1 | 34.2 | 1.75 | 2 | 28 | 30.00 |
| 3 | 24.6 | 14 | 1 | 24.6 | 2.44 | 2 | 28 | 30.00 |
| 4 | 19.8 | 10 | 1 | 19.8 | 3.03 | 3 | 30 | 20.00 |
| 5 | 1.5 | 1 | 1 | 1.5 | 40.00 | 40 | 40 | 1.50 |
| 6 | 9.3 | 5 | 1 | 9.3 | 6.45 | 6 | 30 | 10.00 |
| 7 | 6.9 | 3 | 1 | 6.9 | 8.70 | 9 | 27 | 6.67 |
| 8 | 34.2 | 14 | 1 | 34.2 | 1.75 | 2 | 28 | 30.00 |
| 9 | 24.6 | 14 | 1 | 24.6 | 2.44 | 2 | 28 | 30.00 |
Total | 185.1 | 175 | 185.1 | 188.17 |
A cleaner Google Spreadsheet read-only version is available here;
and an excel spreadsheet for your own use can be downloaded from here
How to use this table:
Basically, this table represents one load test scenario. So each of the row entry is a separate VUser group that is included in this scenario. Under VUser Group Column, the name of user group can be entered. If less or more VUser groups are needed to include in test scenario, rows can be removed or added accordingly.
There are 3 values that need to be entered for each user group: the base load that is desired for that user group, the number of virtual users that are to be used, and a multiplier (which in most cases can be 1). These are explained below:
Base Load: This is the load (in transactions per minute) at which that particular user group will be run. This is a user provided value based on actual requirements of the load test. The Total in last row gives the total load (in TPM) for this whole scenario. The total may or may not mean much but it does provide the total TPM at a glance.
Number of Virtual Users: This is the number of virtual users that will be used to run that user group. This is also a user provided value. Determining this will be a little trickier and there will have to be some estimation involved if you have a small number of VU licenses available (as I do). You will need the estimated time taken by a complete iteration of the transaction represented by this VUser group. Once you have that, you'll have to use enough virtual users to keep VU Pacing of this group above that number. Actually, you should use more Virtual users than that because in a load test, transaction time will vary depending on how stressed the test servers are and may be higher than the times you see when running a single user.
Let me use an example:
For my user group 1, I need to generate a load of 30TPM and I know by running the script with a single user that it takes around 10 seconds to complete one iteration. I want to keep the pacing much above 10 seconds, say at least 60 seconds. Its not difficult to see that I'll need to use 30 users to achieve a pacing of 60 seconds. I can just put 30 in the Number of VU Column and find out what the ramp up and pacing values will be.
VUser Group | Base Load (TPM) | Number of VU | Multiplier (Load Factor) | Expected Load (TPM) | Expected Ramp Up (seconds) | Actual Ramp Up (seconds) | VU Pacing (seconds) | Actual Load (TPM) |
| 1 | 30 | 30 | 1 | 30 | 2.00 | 2 | 60 | 30.00 |
Also, if more virtual users are available, they can be used based on the requirements and/or a desire to increase the VU pacing even more. So if I want to use 100 users for this user group, the numbers will be:
VUser Group | Base Load (TPM) | Number of VU | Multiplier (Load Factor) | Expected Load (TPM) | Expected Ramp Up (seconds) | Actual Ramp Up (seconds) | VU Pacing (seconds) | Actual Load (TPM) |
| 1 | 30 | 100 | 1 | 30 | 2.00 | 2 | 200 | 30.00 |
On the other hand, if I have only 15 users available for this group, the values will be:
VUser Group | Base Load (TPM) | Number of VU | Multiplier (Load Factor) | Expected Load (TPM) | Expected Ramp Up (seconds) | Actual Ramp Up (seconds) | VU Pacing (seconds) | Actual Load (TPM) |
| 1 | 30 | 15 | 1 | 30 | 2.00 | 2 | 30 | 30.00 |
Now to achieve 30TPM with 15 users, I will have to use a pacing of 30 seconds which is much closer to 10 seconds. But in real life with limited number of virtual users available, I may have to go with these values and hope that the iterations don't take more than 30 seconds during the test.
There is another thing to keep in mind: With this table, the values will be accurate if the expected load for each user group is less than 60. If it is more, the expected ramp up will be less than a second and it will be rounded off to 0 or 1. If it is zero, you'll get a division by zero error in Actual Load Column and if it is 1, you'll get the maximum Actual Load of 60.
So the thing to do if you want to calculate the values for loads above 60TPM is to break the group into 2 different groups. For example, to generate the values for 90TPM load, you can break it up into 2 groups of 60TPM and 30TPM. That way, you can generate 90TPM accurately. Other thing that can be done is to ramp up more than 1 user per interval. So with 90TPM, the expected ramp up will be 0.67 per user which means 3 users in 2 second ramp up scheme. This calculation will have to be done manually as the spreadsheet doesn't take care of fractional ramp up values and rounds them to nearest integer value. (see more of this under Actual Ramp Up)
Multiplier (Load Factor): This column solely exists because I had to run different tests at different loads (for example, a stress test that was run at 5 times the load of general load test) and I wanted to quickly find out how many users will be needed at different load factors and what will be their ramp up and pacing values. For example, if I had a user group with 1.5TPM load and 1 user with a pacing of 40 seconds and wanted to find out how many users will be needed to have the same pacing but with 5 times the load, I can use a Load Factor of 5 to find out that I'll need 5 users to maintain a pacing of 40 seconds, as shown in table below:
VUser Group | Base Load (TPM) | Number of VU | Multiplier (Load Factor) | Expected Load (TPM) | Expected Ramp Up (seconds) | Actual Ramp Up (seconds) | VU Pacing (seconds) | Actual Load (TPM) |
| 1 | 1.5 | 5 | 5 | 7.5 | 8.00 | 8 | 40 | 7.50 |
So based on these 3 values entered for each user group, the remaining values, namely Ramp up time, Pacing and Actual TPM achieved are calculated.
Expected Load (TPM): This is calculated by simply multiplying base load with the load factor.
Expected Load (TPM): This is the theoretical ramp up time that is required to achieve the expected load and is calculated by dividing 60 by expected load. For example, if expected load is 30TPM, the ramp of course will be 60/30 = 2 users per second.
Actual Ramp up: Since the theoretical ramp up calculated in previous column can be a fractional value (indicating millisecond ramp up times) and we can have actual ramp up times only at a 1-second granularity, the actual ramp up is calculated by rounding off the expected ramp up to nearest integer. For example, if the expected load is 18TPM, the expected ramp up will be 3.33 seconds. This has to be rounded off to 3 seconds. This has the obvious effect of making the Actual Load different than the desired load.
Another case to watch out for, as I mentioned earlier is when the expected load is above 60TPM. In this case, the expected ramp up time is always going to be less than 1 and the actual ramp up will get rounded up to 0 or 1. The maximum Actual Load will be 60 as I'm not accounting for ramp ups greater than 1 user per second.
However, for both the above cases, there are 2 ways you can achieve the actual load that is closer to the desired load:
1. Break the group into multiple groups: For example, a 90TPM group can be broken into 2 groups - one with desired load of 60TPM and other with 30TPM. This way, an actual total TPM of 90 can be achieved.
VUser Group | Base Load (TPM) | Number of VU | Multiplier (Load Factor) | Expected Load (TPM) | Expected Ramp Up (seconds) | Actual Ramp Up (seconds) | VU Pacing (seconds) | Actual Load (TPM) |
| 1 | 60 | 60 | 1 | 60 | 1.00 | 1 | 60 | 60.00 |
| 2 | 30 | 30 | 1 | 30 | 2.00 | 2 | 60 | 30.00 |
In case of 18TPM, it can be broken into 2 groups of 15 and 3TPM. The values will be:
VUser Group | Base Load (TPM) | Number of VU | Multiplier (Load Factor) | Expected Load (TPM) | Expected Ramp Up (seconds) | Actual Ramp Up (seconds) | VU Pacing (seconds) | Actual Load (TPM) |
| 1 | 15 | 30 | 1 | 15 | 4.00 | 4 | 120 | 15.00 |
| 2 | 3 | 6 | 1 | 3 | 20.00 | 20 | 120 | 3.00 |
2. More users per second ramp-up: Another way is to have multiple users per ramp up interval. For example, 90TPM with a single user group can be achieved by having a ramp up of 3 users every 2 seconds. Similarly, 18TPM can be achieved by having a ramp up of 3 users every 10 seconds.
I usually prefer the 1st method and choose the start time so that the ramp ups are even between the multiple groups of same user type. However it does make it more tedious as I have more user groups to keep account of. The 2nd method has the drawback of introducing a relative burst of users every ramp up interval.
VU Pacing: This is the interval between iterations and is calculated by multiplying the ramp up value with the number of users. Again, you have to make sure that the pacing value is comfortably above the single user transaction time; otherwise if the transactions take longer than the pacing value and next iteration is started immediately after the previous iteration, it may effect the load pattern.
Also, I'm assuming that you are pretty much content with having a stable pacing. If you want to add certain randomness to the the pacing times, that can also be done using this value. See my previous post for more on this here.
Actual Load: Finally, the Actual load is calculated by dividing 60 by the actual ramp up value. This is the actual load that you can hope to generate during your load test for this user group. What is actually generated during the load test depends on a lot of other factors like how stressed your system is etc. This can be found out by analyzing the results of the load test.
So that's that. It turned out to be a longer post than I expected, but hopefully it helps. If you have any comments or think of any suggestions to improve it, let me know.
