The default user load strategy is a ramp-up followed by a peak of concurrent users. You can edit the maximum number of simulated users by editing the Maximum concurrent users field and change the test duration by updating the field Total duration.
Changing these values will update all the steps. The load curve will remain identical but aligned with the new max duration and max concurrent user settings.
Strategy Curve Edition¶
You can also change the shape of the curve (to create multiple steps or add a starting delay) by:
- Resetting the entire curve to a preset,
- Clicking on the graph to add a point/step,
- Dragging and dropping a point across the chart,
- Clicking on a point to edit its values.
At any time you can reset to one one the basic ramp up/down load policies using the
Reset strategy section:
It is also a good way to add a specific number of steps by clicking the
+ button as many times as required.
This can be an easy way to get something close to your needs that you can then edit.
Add a point¶
You cannot drag a point before its predecessor or after its successor. But you place arbitrarily change its value by clicking on it.
Move a point¶
You can drag and drop points to quickly edit the user load curve.
Edit a point¶
When you click on a point, the Step edition panel is displayed:
The current step position can be updated by changing the values of the Concurrent users and Time fields.
The button lets you go back to the user load scale configuration.
The Previous and Next button allows you to quickly navigate through the steps of the user load strategy.
The Delete button removes the current step. The first step (at time 0) cannot be removed. Your curve must also have at least two points.
Press CTRL and click on a point to quickly remove the associated step.
Several options are available by clicking on the Advanced Configuration button:
On Sample Error policy¶
The error policy defines what to do when an error occurs (i.e. an assertion failed):
- Continue: the error is ignored and the test goes on.
- Start next VU Iteration: the current Virtual User iteration is stopped and a new one is started.
- Stop VU: The current Virtual User execution is completely stopped.
- Stop Test: The all load test is stopped gracefully.
- Stop Test Now: The all load test is stopped immediately.
The iterations field lets you limit the Virtual Users execution to a number of iterations.
You still need to set up a duration for the User Profile, so make sure that the execution of all iterations wil not take more time than the specified duration.
You can also override think times for all actions of the selected Virtual User in this tab:
Select Thinktime in the dropdown menu to activate the think times override.
Then you can switch between 3 different modes by clicking on the left buttons:
- Constant: All think times have the same value.
- Range: Think times vary between a lower bound and an upper bound.
- Text: All think times have the same value defined in milliseconds but the value can be passed through a variable like
Throughput is another option for think time. When selected the think times will be adapted on the fly to try to match the requested hit rate for each virtual user running.
Typically with 10 hits per second and 100 users, you can expect a total of 1000 hits per seconds, provided your application can answer fast enough (in less than 1/10th of a second in that example):
Activating this option will automatically disable pacing since it is another way to achieve a similar goal.
This option is incompatible with the follow redirects and Download resources options because both can generate an unpredictable amount of hits per request. You can deactivate Download resources from the Device tab.
Iteration pacing is another way to achieve a controlled injection rate for your tests. The way it works is as a minimum delay for each iteration.
For example if the virtual user iteration is finished in less than 55 seconds, this pacing will wait until 55 to 60 seconds elapsed before running another iteration:
This way instead of controlling hits for all requests, you control the number of iterations you will execute over a period of time.
Activating this option will automatically disable Throughput since it is another way to achieve a similar goal.
A fixed value can be used by providing the same number in From and To. This option is compatible with the follow redirects and Download resources options because it applies at the iteration level, whatever the number of requests executed.
Pacing occurs at the end of an iteration. For that reason, if the current iteration is stopped because of an error policy or any other similar mechanism, the pacing will not be applied.
Set Up and Tear Down are virtual users (or threads in the JMeter language) that will execute before or after the main virtual user. They can be used to conduct preparation or cleaning actions that would be otherwise harder to schedule properly.
A 10 minutes test using both would have an Active users curve like this:
As you can see Set Up threads add up to the overall duration of your tests. Make sure to leave room for them to execute otherwise the Main threads might be stopped earlier at the end of the planned duration. Tear Down threads on the other hand will execute at the end of the planned duration.
Most of the settings on this screen are similar to what you can configure for the main virtual user, so we will only look at the ones specific to Set Up/Tear Down users. Please refer to the sections above for information on others.
The time spent in setup thread groups will be taken out of the total testing time, so make sure to take this into account when planning your tests. A good practice is to use the lifetime parameter to control how long it will last.
You have two options for the scope:
- Local means every load generator during the test will execute a local Set Up/Tear Down
- Global means we will execute the Set Up/Tear Down on one load generator only, this is useful to conduct a unique action for the entire test.
Maximum concurrent users¶
Here again two options:
Onemeans only one virtual user will be run. (or one per load generator if the scope is
Same as main VUmeans one Set Up/Tear Down per main virtual user (based on the maximum number specified in Strategy), this is useful if you need to create a unique value for each user of the main virtual user.
Ramp up period¶
That parameter is only relevant when using the above Same as main VU setting. It will define how fast the Set Up/Tear Down will ramp up. Which is especially useful to avoid overloading your application or the load generators.
Same user on each iteration¶
This checkbox will guarantee that cache and cookies are kept when running several iterations. Otherwise the default behavior is to get rid of them everytime.
Virtual user lifetime¶
This value define the minimum AND maximum duration of each Set Up/Tear Down user.
It is a very good tool to control how much time is allocated for those. Otherwise the main virtual user could be delayed indefinitely if one of the Set Up/Tear Down users times out.
For example for a Set Up user with a ramp up of
1 minute and
2 minutes of lifetime, you know the main virtual user will start after
2 + 1 = 3 minutes have passed. And that way you can predict the time allocated to the main user for this test.
A more detailed explanation is that:
- Since it is a minimum duration, each Set Up/Tear Down user that would finish before reaching that time will wait until
lifetimeduration has been reached,
- Since it is a maximum duration, each Set Up/Tear Down user that would not be done when
lifetimeduration has been reached will be forcefully shutdown.