Configure the Controller

The NeoLoad Controller orchestrates the test scenarios and is in charge of communicating with the Load Generators and aggregating test results. The Controller needs a certain amount of memory and CPU resources to carry out its duties. Specific points must be taken into account to optimize the Controller prior to heavy load testing.

Launch scenarios with a fixed duration

During the testing phase, NeoLoad continuously aggregates and computes results. Defining tests with an unlimited duration forces NeoLoad to store intermediate results during the test. This consumes both time and resources; all the more so for heavy load tests.

For these reasons, it is advised to avoid starting heavy load tests using scenarios of unlimited duration. Instead, limited durations must be specified and an iterative and incremental approach must be used in which the total duration is augmented in several steps.

Monitor using a top-down approach

Rather than monitoring the whole infrastructure at once, a top-down approach is recommended by targeting general metrics at first and then by refining those metrics when the source of the problem is identified more precisely. This avoids NeoLoad having to manage large amounts of non-significant monitoring data. For a first run targeting a heavy load, the default Monitor configuration defined by NeoLoad is usually adequate.

Control error management

To save resources, NeoLoad makes it possible to set the content and the number of logged errors:

Avoid debug mode

To save resources, it is recommended to avoid the debug mode for heavy load testing. For more information, see Start the test.

Avoid Virtual Users status display

NeoLoad makes it possible to view each Virtual User in a scenario and the Containers being executed, as described in Monitor a Virtual User at runtime.

This function is very memory-consuming. In heavy load tests, it is strongly recommended to disable the option in the scenario Advanced parameters. For more information, see Scenario advanced settings.

Warm up the application server

Heavy loads are best achieved by gradually increasing user load.

Rather than applying a sudden, large load (which, other than being unrealistic, is likely to cause the server to crash), sending a short, light load at the beginning of the scenario allows certain resources, such as connection pools or thread pools, to be allocated for the first time.

It is advised to start the Virtual Users of a Population over a defined period of time rather than starting all the users simultaneously. This setting is accessible in Runtime section, by clicking the Advanced button for the selected Population in the runtime policy settings dialog box. For more information, see Population advanced parameters.

Plan for large amounts of memory for the NeoLoad Controller

Aggregating results is a memory-consuming task for the NeoLoad Controller. It is necessary to plan for a JVM that can provide the Controller with a large enough memory allocation.

  1. Edit the <install-dir>/bin/NeoLoadGUI.vmoptions and <NeoLoad>/bin/NeoLoadCmd.vmoptions files.
  2. Edit the VM argument:

    For x64, default settings are:


    VM will use maximum 1/4 of total system memory.

Information: For x86, default settings are: -Xmx800m. This means that the VM will use maximum 800 MB of total system memory.

Save projects locally

The NeoLoad Controller stores and keeps track of all the results of your tests using files stored on disk. Load testing, particularly heavy load testing, can generate very large files.

To minimize network traffic, it is advised to keep those files on local disks rather than on network drives.

Adjust Load Generator start-up timeout

When a test is started, the NeoLoad Controller sends the project data to each Load Generator in several steps. By default, each step of this data transfer from the Controller to a Load Generator must be completed within five minutes.

If this period times out, the Load Generator cannot be used for the test. To increase the time allowed (in milliseconds), it is necessary to add the key loadGenerator.init.touch.delay to the Runtime category in the <Controller>/conf/ file. For example, using loadGenerator.init.touch.delay=600000, a maximum of ten minutes is allowed for sending each step of the project data to the Load Generator.