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.