Setting user loads

By setting stages, you can model workloads over time and change the number of users that perform certain tasks to reflect real-world usage. You can vary the user load and collect performance metrics for each stage independently, which means that a single run can more efficiently accomplish the work of multiple runs that require shutting down and restarting users. Each stage, which lasts a specific amount of time and contains a specific number of users, defines a different load.

About this task

When a schedule contains stages, you can place the tests in the schedule in an infinite loop, as shown in the following figure. This setting prevents virtual users from finishing the stage before the allotted time.
tests contained in infinite loop
You can also use the Percentage of users allowed to exit during execution option to specify the number of users that can stop during a stage without stopping the stage or the entire test run.

Procedure

To add stages to a schedule:

  1. In the Test Navigator, browse to the schedule and double-click it. The schedule opens. By default, the User Load tab contains one stage with five users that run until finished. The following figure shows the default User Load tab.
    user group with one stage
  2. On the User Load tab, click Add.
  3. In the Create User Stage window, enter the information for a schedule stage, and click OK.
    Option Description
    Number of users Enter the total number of users in the stage. This is not the number of users to add to or to remove from those currently running; it is the total number of active users at this stage.
    Stage Duration Enter the length of time (and the time units) for the stage to run. After the Number of users setting is achieved, the users will run for up to this amount of time. When the time expires, the users continue to run if they are needed for the next stage, or, if not, they are stopped.
    Rate of Change Specify the amount of time to delay, when changing the number of users, between adding or removing each user.

    Adding or removing all users over a time period changes the users in a uniform random distribution over the time specified for changing users, which is the time before the settle and the stage begin. This slight variance closely emulates human behavior.

    Adding or removing one user every time unit adds the same delay for each user. Although this option does not emulate human behavior as closely as the first option, it is useful when you must adhere to a certain rate because of limitations of the system under test, such as the time it takes for a user to log on to the system.

    Settle Time After the desired user population has been reached, a system might still experience a period of flux in reaction to the change in user population. Setting a settle time allows the system to re-establish its steady-state equilibrium so that it can accurately reflect the user population.

    The Stage Duration starts after the settle time expires. The settle time is not part of the stage duration and the settle-time metrics are not included in the Compare report, which is generated at the end of the run. However, settle time does affect how long a schedule runs, because it adds time to the beginning of each stage. And, although the Compare report does not include the settle-time metrics, these metrics are collected and you can include them by changing the time range of the report.

    If your system does not have significant flux or if the stage is long enough that the flux comprises only a minor part of it, you might not need a settle time.

  4. On the User Load tab, modify the stages as necessary:
    1. Click Up or Down to change the order of the rows.
    2. Double-click a row to modify it.
  5. Enter the Time limit for a user to respond to a stop request value. If a stage contains fewer virtual users than its predecessor, the excess users are asked to stop. This value gives a stopped virtual user extra time to complete its current action (such as an HTTP request). If the virtual user cannot complete its action before the time limit expires, it is forced to stop. Note that a long time limit might delay the next stage.
  6. Enter a value for Percentage of users allowed to exit during execution to specify the percentage of users that can stop during a stage of a test run. The default is 0%, which means if any users stop during a stage, the entire test ends after that stage completes. If you enter a value, the test run can continue to the next stage even if some users stop running. You can specify a value from 0 to 100 with fractions up to one decimal place. Examples of valid percentages include 0.5%, 3%, and 99.1%.
  7. To stop the schedule run after a specific number of successive failed stages, select the Exit run for failing requirements check box and specify a value in Number of failing stages in a row. If, at the end of a completed stage, that stage has failed, and if such stage failures happen successively for the specified number of times, the schedule will stop.
  8. Examine the User Load Preview section to verify that the stages are set correctly. The red line segments indicate that the total number of users has been achieved for the stage and the settle time, if one is specified, has ended. The following figure illustrates a schedule with two 16-minute stages. The second stage has a 4-minute change rate and a 4-minute settle time:
    user group with 5 stages

What to do next

You can display a Compare report, which compares the time ranges of each stage, when the run is complete. This report provides a quick side-by-side analysis of how the system under test performs under various user loads. To display a Compare report, right-click the test results; then click Compare All Time Ranges.

To display a Compare report automatically at the end of each staged schedule run, click Window > Preferences > Test > Test Reports, and select Launch Compare report when staged run completes.

Related concepts:
Schedule overview
User group overview
Working with agents
Related tasks:
Creating a schedule
Adding a test to a schedule
Adding must run tests
Assigning variables to schedule and user group
Defining performance requirements in schedules
Repeating tests in a schedule
Delaying virtual users or actions
Running tests at a set rate
Running tests in random order
Adding a transaction to a schedule
Synchronizing users
Emulating network traffic from multiple hosts
Setting log and statistic levels
Related reference:
Schedule properties

Feedback