Table of Contents
A scenario contains all the settings required to run a load test:
the test duration,
which populations to test,
the load policy, i.e. the number and variety of virtual users to be generated,
which load generators should run the test and,
the runtime policy.
NeoLoad can generate several scenarios for each project, making it easy to switch from one test configuration to another: a short test with a ramp-up load, a very long test with load peaks, a test with a realistic load etc..
The simulated load in a scenario is determined by a duration and a number of virtual users. Each virtual user plays the pages contained in its profile, then stops. NeoLoad immediately runs another virtual user with the same profile to maintain the predetermined load.
Sets the population duration : unlimited, set time, or iterations.
One iteration represents one virtual user played once, through to its end.
When iterations are selected, a population's runtime must be defined by
entering the number of iterations in the "Duration
Policy" panel.
In any event, a test can be stopped at any point by clicking on the
"Stop" button.
Specifies the number and variety of virtual users to be generated. Select one or more populations to test and the load policy for each population:
Constant - Generates a fixed number of virtual users.
Ramp-up - Generates a number of virtual users that increases throughout the test. Useful for checking the server's behavior under an increasing load.
Peak - Generates a fixed number of virtual users with periodic phases of high load. Useful for checking whether the server recovers its normal behavior after a load peak.
Custom - Allows you to set the load to be applied by plotting the virtual user variation curve. You may import the curve using a CSV file. The file must be in the format
Time (seconds) <separator> Number of users.
In this mode, the population is played for the number of iterations specified in the panel. Each simulated user is run for a predetermined number of iterations without any break between iterations. Towards the end of the test, some users will have finished their iterations and some others will still be active, which is why the load decreases until all the users are finished.
For ramp-up or peak load, adding users for a new phase takes place once all existing users have finished their iterations. Before each new phase therefore, and depending on the virtual user definition, the load may drop to 0.
Constant - Defines the number of play iterations for the virtual users.
Ramp-up - The "Number of iterations" field allows you to set the test duration, since the test ends once each virtual user launched for a first iteration completes the number of iterations entered in the "Number of iterations (for each initial user)" field. Subsequent users launched at each increment do not affect the test duration.
Example: a ramp-up load of 10 users, incremented by 2 users every 5 iterations. Running the test with the number of iterations set at 20 will give the following load:
10 users for 5 iterations
12 users for 5 iterations
14 users for 5 iterations
and finally 16 users for 5 iterations. (The test ends once the first 10 users have completed 20 iterations.)
Peak - The "Number of iterations" field allows you to set the test duration, since the test ends once each virtual user launched for the first peak stage completes the number of iterations entered in the "Number of iterations (for each initial user)" field. Subsequent users launched for each peak do not affect the test duration.
Example: a minimum peak load of 10 users for 5 iterations and a maximum peak load of 20 users for 3 iterations. Running the test with the number of iterations set at 20 will give the following load:
10 users for 5 iterations
20 users for 3 iterations
10 users for 5 iterations
20 users for 3 iterations
and finally 10 users for 4 iterations.(The test ends once the first 10 users have completed 20 iterations.)
Custom - The number of virtual users to be launched and the number of iterations are set by plotting the load curve. You may import the curve using a CSV file. The file must have the following format :
iteration count <séparateur> Number of users.
The load generator is the program that simulates the application users. Each NeoLoad controller features a load generator. Load generators may be installed as separate programs on other machines.
The Load Generator Hosts list shows the load generators available
for use. Each load generator running on the local network is automatically
detected by the controller on start up. Click
"Discover" to auto-discover the load generators
currently running (the discovery make take a few seconds). Load generators
may be declared manually by entering the list of host names or IP addresses.
Load generators that are running are indicated by a green light; those that are halted by a red light; and those that require an update by an orange light (See the section called “Automatically updating load generators”).
Select the load generators to be used for each population. The controller distributes the virtual users among the selected, running load generators.
This panel lists all the network interfaces detected for the load generator. For those hosts acting as network routers for several networks, select the network card to be used by the load generator. All the host's IP addresses are listed on the selected interfaces. By default, a single IP address is selected and all the virtual users generated by that load generator use that same address.
Defining several IP addresses allows the user to test applications that use a load balancer based on IP addresses. In this case, a random IP address is assigned to each virtual user. The IP addresses must be available, i.e. not used by other machines within the network. Check with a system administrator to make sure these addresses may be used.
To define IP addresses in the list, define additional IP addresses in the load generator's operating system settings.
These parameters will modify the load generator's network settings. Please check with a system administrator before changing the host's settings. In some documentation, multiple IP address settings are referred to as virtual IP settings.
Windows.
In the
Startmenu, clickControl Panel.In
Network Connections, right-click onLocal Area Connectionand selectPropertiesSelect
Internet Protocol (TCP/IP)in the list, then click on thePropertiesbutton.Multiple IP address configuration is not available in DHCP mode. If DHCP mode is set (i.e. "
Obtain an IP address automatically" is selected), this setting must be changed to the static IP mode (i.e. "Use the following IP address").Click on the
Advanced buttonto display the list of defined IP addresses. Click on theAddbutton.Enter the new IP address and subnet mask in the appropriate boxes. Then click on the
Addbutton.The new IP address should appear in the list.
Repeat steps 5 through 7 to define each IP address.
Linux. Multiple IP address configuration is not available in DHCP mode. Change the settings to use static IP addresses. Use the
ifconfigcommand to add a new IP address.For example, the command line for adding 2 new IP addresses (say, 192.168.1.10 and 192.168.1.11) to the eth0 network interface would be:
ifconfig eth0:0 192.168.1.10 ifconfig eth0:1 192.168.1.11
The virtual users used in the test are spread among all the available load generators. All the load generators generate the same number of virtual users by default.
Increasing the load factor proportionally increases the number of virtual users created by each load generator. For example, where NeoLoad needs to creates 5 more virtual users and load generator A has a load factor of "3" and Load generator B a load factor of "2", A will create 3 virtual users and B will create 2. The more powerful machines may be configured to create a greater number of virtual users.
A NeoLoad controller can automatically update obsolete load generators (orange indicator in the list). This is particularly useful after a controller update.
Procedure 8.1. Updating a Load Generator
In the
"Scenarios"tab, click on the "Modify..." button in "Load Generator Hosts" section.Click on the load generator's Edit button.
Click on the "
Version" tab.Click on the "
Update" button (twin arrows icon). If the update is unavailable or unnecessary, the button is grayed-out.
When the test is launched, NeoLoad checks the versions of the load generators being used and prompts the user to update those that are obsolete. Once the load generators have been updated, the test continues as normal.
A controller cannot update a load generator handled by a different controller. In this case, perform a manual update using the standard installer.
If the load generator's agent has been started with an account that does not have privileges required to update the program, then the load generator cannot be updated automatically. In this case, perform a manual update using the standard installer.
![[Important]](images/important.png) | Important |
|---|---|
If the update fails, or if the load generator fails to function properly after an automatic update, perform a manual update using the standard installer. |
![[Note]](images/note.png) | Note |
|---|---|
This function is only available for load generators having the same major and minor version numbers as the controller. For example, the controller version 3.1.2 can update the load generator 3.1.0 but cannot update the version 3.0.9. When the automatic udate is not supported, the load generators must be updated manually using the standard installer. |
In this section, you can define the following:
Start policy - Defines how the population is started:
"Immediate": the population is started at the beginning of the test."Delayed": the populations starts after a preset delay."Sequential": the population is started once the selected population has finished.
How virtual users start may also be defined: simultaneously or with a preset delay. This policy is used each time new virtual users are created, either at each load increase for a ramp-up load policy or at each load peak for a peak load policy.
Stop policy - Defines how the population is stopped:
"Immediate": the users are stopped at the end of the time set for the population; they do not finish their actions."Delayed": set a timeout for virtual users to end their actions before they are stopped."Unspecified": the virtual users are given time to finish their actions.
The following settings can be edited for each scenario:
Scenario properties - name and description of the scenario.
Advanced Runtime:
Virtual users: enable or disable the real-time display of virtual users.Monitoring settings: enable a monitoring period before and/or after the test. This allows you to check the stressed server's behavior prior to running the test and the load test's impact upon it.
Debug mode: This mode logs the runs (requests and responses) of all the virtual users. See the documentation on starting a test in debug mode.
There are two logging levels:
Only virtual users containing errors.
All virtual users.
![[Warning]](images/warning.png)
Warning Launching a scenario in debug mode can severely hamper performance, especially when too many virtual users are started on a single load generator.
To carry out a large-scale test, we recommend you use several load generators with lighter loads.
Details of the virtual users' runs are available in the test results in the "
Debug" tab. See the documentation on debug mode for more details.
For detailed information on configuring rendezvous policies, see the documentation on configuring a scenario's rendezvous.
NeoLoad allows you to schedule a test at a specified time.
Procedure 8.2. Scheduling a test
Select the scenario to be run.
Click on the "
Advanced..." button.Select the "
Schedule a test" tab.Check the "
Activate scheduling for this scenario" check box.Select a date and time.
Enter a repeat rule (optional).
Enter a test description (optional).
Click
"OK".
| Note |
|---|---|
NeoLoad must be running at specified time to be able to run the tests. |
