The business requirement: The website will be subject to 100.000 users per hour.
Analyzing real user behavior it is found that a typical user spends 15 minutes on the site, and browses 10 pages on average.
This means the implemented user scenario will contains 10 page-requests and each virtual user will run for 15 minutes.
To calculate the necessary number of users, we use the following basic formula:
Analyzing real user behavior it is found that a typical user spends 15 minutes on the site, and browses 10 pages on average.
This means the implemented user scenario will contains 10 page-requests and each virtual user will run for 15 minutes.
To calculate the necessary number of users, we use the following basic formula:
Number of required VUsers = Required requests per seconds * User scenario length (sec)
Note: The requests-per-second-based approach (or in our case Transactions-per-Second, as we assume 1 request=1 transaction) is an adequate approach, as Load runner also uses Transactions per second when displaying metrics data.
Using the above requirements the number of virtual users can be calculated using the following formula:
In practice scripts are not created with lengthy think times. A 1 second think time is usually the pragmatical approach. The recorded think times of the script can be scaled down or can be limited to a configured length. The Think Time run time settings’ “User random percentage of recorded think time” and “Limit think time to” options control this.
Note: The requests-per-second-based approach (or in our case Transactions-per-Second, as we assume 1 request=1 transaction) is an adequate approach, as Load runner also uses Transactions per second when displaying metrics data.
Using the above requirements the number of virtual users can be calculated using the following formula:
No. of required VUsers = (number of site users per hour * requests per user /
3600) * user scenario length (sec)
Using the above formula:
Using the above formula:
Number of site users per hour := 100000 users (100k)
Requests per user := 10 reqs
User scenario length (sec) := 15 minutes * 60 seconds = 900 sec
required transactions per hour (TPH) := number of site users per hour * requests per user
required
Transactions per seconds = required transactions per hour (TPH)/(60 minutes * 60 seconds)
number of required VUsers := number of site users per hour * requests per user /
3600 * user scenario length (sec)
3600 * user scenario length (sec)
number of required VUsers = ((100000 * 10)/3600 )* 900 = 250000 Vusers
250,000 virtual users are required to create the appropriate load.
Well. This calculation is fine, but not very efficient
Notice, that in our implementation each virtual user will run for 15 minutes, but they are idle for most of the time (as each user performs 10 requests altogether).
Here is a better solution: We know that each request is likely to be quick (let’s say quicker than 1 second).
250,000 virtual users are required to create the appropriate load.
Well. This calculation is fine, but not very efficient
Notice, that in our implementation each virtual user will run for 15 minutes, but they are idle for most of the time (as each user performs 10 requests altogether).
Here is a better solution: We know that each request is likely to be quick (let’s say quicker than 1 second).
So we compact the user scenario: the script can perform the scenario in 15 seconds instead of 15 minutes.
The think times can also be reduced from 1.5 minutes to about 1 seconds accordingly.
After recalculating the number of required virtual users, we find that we need only 4166 virtual users to simulate the required load. This is a significant difference!
After recalculating the number of required virtual users, we find that we need only 4166 virtual users to simulate the required load. This is a significant difference!
In practice scripts are not created with lengthy think times. A 1 second think time is usually the pragmatical approach. The recorded think times of the script can be scaled down or can be limited to a configured length. The Think Time run time settings’ “User random percentage of recorded think time” and “Limit think time to” options control this.
