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.
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.
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.
To save resources, NeoLoad makes it possible to set the content and the number of logged errors:
max.errors.store.countkey of the
controller.propertiesconfiguration file. It is recommended to keep that default value or set a lower one. For more information, see controller.properties.
maximum.content.errors.storedkey of the
controller.propertiesconfiguration file. It is recommended to keep that default value. For more information, see controller.properties.
To save resources, it is recommended to avoid the debug mode for heavy load testing. For more information, see Start the test.
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.
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.
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.
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.
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.
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/Controller.properties 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.