A Scenario defines how many virtual users should run your scripts in a load test. Each virtual user represents one simulated human user, running a script.
A scenario may have multiple groups of virtual users, with each group running a different script. Additionally, each group of virtual users is given a ramp-up schedule, a total duration at peak load, and a ramp-down schedule.
During the ramp-up schedule, the group of virtual users starts at 0, and adds more virtual users gradually until the target number is reached. Virtual users run the script and repeat it, if necessary, until the duration has elapsed. Then, the number of virtual users is ramped back down to 0.
The number of virtual users you specify in your scenario is the number of concurrent users. This may be different from the total users hitting your application in a given period. If you have 50,000 daily unique users, it’s possible that only 1,000 are active at any given time.
Concurrent Users means the number of human users (or virtual users) active at a particular moment.
Total Users generally means your entire user base, or at least the number of users that are active in a given time window.
This distinction is important, because when creating Loadster scenarios, you want to think in terms of how many concurrent users you will be simulating.
In Loadster, when a virtual user finishes an iteration of the script, it starts another iteration of the same script, as long as there is time remaining in the test. Therefore 50 virtual users, run continuously over a period of time, can actually generate as much traffic as many individual users coming and going.
A load test scenario should be realistic. The mix of behaviors (scripts) should be similar to what you can expect from your real users.
For example, at any given moment, an ecommerce site might have:
It is up to you and other stakeholders to determine what user behaviors are realistic and relevant for your site.
Once you’ve made this determination, you can create Loadster scripts to represent each user behavior, and create a scenario with groups of virtual users running your scripts.
Once you have created one or more scripts, create a scenario by right-clicking on the project in the sidebar. Then click on “New Scenario…” in the provided menu.
The scenario will open in the scenario editor.
A scenario consists of one or more Virtual User Groups. Each group can run its own script, or you can have multiple groups running the same script. Each group can have its own schedule and configuration as well.
Every scenario needs at least one virtual user group in order to run. To create a virtual user group, click the Plus (+) button in the scenario editor.
You can add multiple groups to a scenario, each with its own configuration. When you run the test, these groups will execute in parallel.
To remove a group, select it and hit the delete key.
Adjust the number of virtual users in the group by clicking on the number and typing in a different number.
Each group can have anywhere from 1 to 9999 virtual users.
Each virtual user group is configured to run a script. To select a different script, click on the script name and choose a different one.
You can use any script in the same project as your scenario.
Not all virtual users start at the same second. Instead, they gradually increase the number of running virtual users, continue at peak load for a while, and then the virtual users gradually exit.
Each of these phases (the ramp-up phase, the peak phase, and the ramp-down phase) has its own duration in minutes. You can also select a ramp-up formula and ramp-down formula to determine at what rate the load should be ramped up or down.
If you are trying to simulate realistic production load, we recommend selecting ramp-up and ramp-down formulas that match your real usage patterns. Sometimes, systems can perform well when load increases gradually, but may fail when a burst of traffic arrives all at once.
Each group of virtual users runs on either a self-hosted Loadster Engine, or one of the Loadster Cloud regions. Select the engine or region for this group by clicking on it.
If the site you’re testing is publicly reachable, we recommend selecting one of the cloud regions.
If you need to generate load from a private network, read more about Testing with Loadster Engine.
There are also options to limit the total number of iterations per group, simulate a slower connection speed, or override DNS entries.
There are times when you only want to run a certain number of iterations of your script. For example, you may have a requirement like “the system must process 1000 shipments within a 10 minute period”.
In these cases, Loadster can limit the total number of iterations. This limit is the cumulative limit across all virtual users in the group.
Once the group has reached this number of iterations, virtual users will begin to exit, even if there is time remaining in your test. If the number of virtual users in your group exceeds the number of total iterations, some virtual users may not even start.
Normally, virtual users use all the network bandwidth available to them. If you want to simulate the impact of slower connections, you can configure the group to throttle bandwidth.
Slower clients will experience longer response times. Also, slower clients often cause the TCP connections with your server to stay active longer, which may cause it to hit a max connections bottleneck or other problems, that may not happen when all your clients are on fast connections.
When testing against multiple environments of your application, you may wish to direct traffic to certain hosts. Loadster can accomplish this by overriding DNS name resolution.
This is similar to editing your
/etc/hosts file, but it automatically propagates out to all your engines as well as
Loadster Cloud when you run the test. Only the virtual user group(s) with the override are affected.
You’re ready to run a test! To start a load test, click the Launch Test button in the scenario editor.
Read Running Load Tests to learn more about monitoring and observing your load test.