Performance optimizations

In case of load test executions with extreme high load (or depending on your system capacity), creating and persisting a report for each and every node execution will impact the maximum load your step instance can generate. In such cases, it is possible to disable the persistence of the nodes by setting one or more of the following predefined variables (for instance using a set control):

• tec.execution.reportnodes.persistbefore=false: this will only persist the node state after it execution, thus you won’t see the nodes in RUNNING state but still have all information for your analysis and reporting. Note: this is the default behavior for nodes executed within a threadgroup.
• tec.execution.reportnodes.persistonlynonpassed=true: by setting this options, only nodes which failed (or with technical errors) will be persisted, reducing drastically the pressure but keeping information to analyse error cases.
• tec.execution.reportnodes.persistafter=false: finally this last option combined with the “persistbefore” one will disable the persistence of all report nodes (this is usually not required and not recommended).

The changes on the persistence of report nodes doesn’t impact the creation of the performance measurements, you will always be able to perform the performance analysis and reporting of your execution

Controlling the number of “Multiworkers”

In some contexts, mainly for functional testing, you may want to control the overall number of workers (or threads) to be used when starting a test execution disregarding the values actually set in your plans.

This can ben enabled by adding the following execution parameter in step. Go to the admin screens settings page and create an execution parameter with:

• id: “execution_threads_auto”
• label: “execution_threads”
• type: TEXT

Once done, you will see an additional field when starting a test execution.

How it words: When stating a test by providing a value to this new field, you will set (override) the number of threads/workers that are used by the first nodes implementing a thread pool. This includes among others: nodes of type Testset, For, ThreadGroup. Each child nodes implementing a thread pool will see their number of threads reduced to 1.