Logical actions
< Prev Chapter 6. Design Next >

Logical actions

NeoLoad provides a number of logical actions that can be used to add, for example, delays, loops and containers to Virtual Users, to create more complex scenarios.

Delay

This action pauses the Virtual User for a specified duration. The delay is expressed in milliseconds and may be set as a NeoLoad variable (useful for random delays).

Loop

Used to iterate various items such as pages, the number of iterations being defined by the user. This number may be a variable, in which case the variable will be evaluated once only, before the first iteration.

A variable named <MyLoopName>_counter is created within the loop containing the current iteration number. This value starts at 1, for the first iteration, and is incremented by 1 at each next iteration.

While

The while action allows various items, such as web pages, to be iterated while a condition remains false. A condition is composed of two operands and an operator. The operators are:

  • Equals - true if the 2 operands have the same value

  • Doesn't equal - true if the 2 operands do not have the same value

  • Contains - true if operand1 contains operand2

  • Doesn't contain - true if operand1 does not contain operand2

  • Starts with - true if operand1 begins with operand2, including if the 2 operands are equal.

  • Doesn't start with - true if operand1 does not begin with operand2.

  • Ends with - true if operand1 ends with operand2, including if the 2 operands are equal.

  • Doesn't end with - true if operand1 does not end with operand2.

  • Matches regexp - true if operand1 verifies the regular expression of operand2.

  • Doesn't match regexp - true if operand1 does not verify the regular expression of operand2.

  • Greater than -true if operand1 is greater than operand2.

  • Greater than or equal to - true if operand1 is greater than or equal to operand2.

  • Lesser than - true if operand1 is lesser than operand2.

  • Lesser than or equal to - true if operand1 is lesser than or equal to operand2.

Each operand may be a variable ${VariableName} or a static string.

Several conditions may be used within a while action. To add a condition, simply click on the "+" button below the table of conditions. You must then specify whether the action is executed if all the conditions are true (Resolve all the following items), or if at least one of them is true (Resolve one of the following items).

If ... Then ... Else

The If ... Then ... Else action is used to execute conditional actions. When creating a conditional action, two containers are created, Then and Else. If the condition is true, the actions in the Then container are executed; if false, the actions in the Else container are executed. A condition is composed of two operands and an operator. The operators are:

  • Equals - true if the 2 operands have the same value

  • Doesn't equal - true if the 2 operands do not have the same value

  • Contains - true if operand1 contains operand2

  • Doesn't contain - true if operand1 does not contain operand2

  • Starts with - true if operand1 begins with operand2, including if the 2 operands are equal.

  • Doesn't start with - true if operand1 does not begin with operand2.

  • Ends with - true if operand1 ends with operand2, including if the 2 operands are equal.

  • Doesn't end with - true if operand1 does not end with operand2.

  • Matches regexp - true if operand1 verifies the regular expression of operand2.

  • Doesn't match regexp - true if operand1 does not verify the regular expression of operand2.

  • Greater than -true if operand1 is greater than operand2.

  • Greater than or equal to - true if operand1 is greater than or equal to operand2.

  • Lesser than - true if operand1 is lesser than operand2.

  • Lesser than or equal to - true if operand1 is lesser than or equal to operand2.

Each operand may be a variable ${VariableName} or a static string.

Several conditions may be used within an If ... Then ... Else action. To add a condition, simply click on the "+" button below the table of conditions. You must then specify whether the action is executed if all the conditions are true (Resolve all the following items), or if at least one of them is true (Resolve one of the following items).

Variable Modifier

Using a Modify variable action, you can change the value of a variable defined in the configuration. A variable's value can be changed (take next value) or the variable can be reset (reset to first value). This action allows the variable's value to be changed without affecting its value change policy. For example, you may change the value of the variable within a Virtual User loop.

Specify the variable name on which the action will be performed. Use the name, like "myVar", but not the expression like "${myVar}". Nevertheless, name can be composed: for example "data_for_${login}" if variable "data_for_jsmith" is defined.

Containers

A container allows the user to group certain actions, relating to a business action for example, for statistical purposes. The container is viewed in the same way as other result actions such as web pages. Thus, the user can obtain statistics including average time, hits/sec., etc..

A pacing duration may be set on a container. The pacing time is the minimum time a container must take to execute. If the container's execution takes less time than the pacing time, then the virtual user will wait until the end of the pacing time before continuing the scenario.

For example, if a container has a pacing duration of 30 seconds and the actual time to execute the actions in the container is only 20 seconds, the virtual user will pause for 10 seconds before resuming. On the other hand, if the actual time is 45 seconds, the virtual user will continue immediately.

Random containers

A Random Container is used to specify pages to be played in a random sequence. All the requests in a container may be played, or only some.

  • Play all pages in random sequence. All the pages in the container will be played once, in random sequence.

  • Play a number of pages in random sequence. In this mode, the number of random pages to be played may be selected. At each iteration, one of the pages within the container is chosen at random and played. It is possible therefore that a page might be played more than once.

[Note]Note

Only the top-level actions are randomly executed. If a random container contains a container, and this second container is played, all the actions within that container will be executed in their correct sequence.

A pacing delay may be set on a random container. The pacing time is the minimum time a container must take to execute. If the container's execution takes less time than the pacing time, then the virtual user will wait until the end of the pacing time before continuing the scenario.

For example, if a random container has a pacing delay of 30 seconds and the actual time to execute the actions in the container is only 20 seconds, the virtual user will pause for 10 seconds before resuming. On the other hand, if the actual time is 45 seconds, the virtual user will continue immediately.

Try ... catch

The Try ... Catch action is used to execute specific actions in the case of an error or validation failure. A Try...Catch action can capture errors or assertions (validation errors) or both.

When creating a Try...Catch action, two containers are created: Try and Catch. All the actions in the Try container are executed until an error or assertion occurs (depending on the action's configuration). When an error or assertion occurs, the actions in the Catch container are executed.

[Note]Note

Within a Try container, the Virtual User will not be halted upon the error or assertion's occurrence, even if it is configured so to do.

Stop Virtual User

This action allows the Virtual User to be stopped at a given point in the scenario. This can be especially useful when combined with an If ... Then ... Else action, or Try ... Catch action. To maintain a constant load on the application, NeoLoad immediately runs a new Virtual User.

Fork

The fork action is used to play actions in a different execution thread to the current one. This execution thread is parallel to the main chain used by the Virtual User.

In particular, this action can be used to modelize automatic actions played by the browser while the user is using the web application normally. Let's take the example of an action played every x seconds on the server to refresh a web component (Ajax, Flash plug-in...). This request must be made in parallel to the standard scenario for the Virtual User.

[Note]Note

When the Virtual User's main execution thread stops, all the threads created using fork actions are immediately halted.

[Note]Note

In the Virtual User validation, the actions played as part of a fork action appear in the list at the moment they are executed. This can make reading the validation results more complicated, as the list will contain several overlapping execution threads.

JavaScript

How it works

NeoLoad allows the execution of JavaScript within Virtual Users, which means that a JavaScript action can be inserted when designing a Virtual User. The code used may invoke common JavaScript functions declared in the NeoLoad JavaScript libraries.

What you can do

The NeoLoad API is mainly used to manipulate NeoLoad variables and set up cookies for the current Virtual user. Basic JavaScript functions allow the handling of strings and dates, calculation etc...

the section called “API overview” describes the NeoLoad API's features.

What you cannot do

The script does not run within the context of the HTML request, so manipulating a request response's DOM tree is impossible. Consequently, functions built into browsers for extracting or manipulating the HTML document are not included.

The following is a non-exhaustive list of functions or objects that are not supported:

  • window

  • document (of which document.cookie, document.forms[0], document.getElementById(), ...)

  • navigator

  • alert()

  • confirm()

  • ...

Note that scripts using these objects compile correctly but their running will halt when it reaches the non-supported object.

JavaScript actions

A JavaScript action may be added to a Virtual User's definition. A JavaScript action is identified by a name and a description and contains the script to be executed.

Creating a JavaScript action

The procedure is as follows:

Procedure 6.10. Create a JavaScript action

  1. In the "Design" section, click on the "Virtual User" tab.

  2. Select the JavaScript logical action.

  3. Drag and drop the action at the desired point in the Virtual Users tree.

NeoLoad creates the action using an outline script, which you can either adapt to your requirements or delete to begin a new script.

Editing a JavaScript action

Any changes made to a script during the editing process must be validated for them to be applied. Alternatively, changes may be canceled prior to validation, in which case the last script version saved will be reloaded. Scripts may be edited directly in the project files ('scripts' directory). The content of the edited file can then be reloaded into NeoLoad by clicking on the "Reload" button.

You may compile your JavaScript scripts prior to running. Compiling will check the script syntax (missing parentheses...) but not its validity (method names ...).

Errors

During a test, a JavaScript action will be flagged as an error in the following cases:

  • The script doesn't compile. (Syntax error)

  • The script is invalid (a method does not exist)

  • The script calls the API's context.fail(message) method.

JavaScript actions are systematically displayed during a Virtual User verification and will appear in the error table if the script has been error flagged.

JavaScript libraries

JavaScript libraries allow the user to create functions that can be used in all the Virtual User scripts. Libraries not only allow code sharing between several scripts, they also help reduce memory usage on the Load Generators, since the code stored in the libraries is shared by the users, whereas code contained in scripts is loaded into memory for each Virtual user. It is therefore recommended, wherever possible, to use functions whose code is stored in a library.

Creating a JavaScript library

A JavaScript library is identified by its name and library file. You may use an existing file or create a new, empty file. Each library may contain one or several JavaScript functions.

Procedure 6.11. Create a JavaScript library

  1. Select the Edit / JS Libraries menu item.

  2. Click on "New library"

  3. In the following wizard, enter the name of the library.

  4. Choose either to create a new library or use an existing file, whichever is appropriate.

  5. Confirm the choice to exit the wizard.

  6. Select the created library in the library list.

Editing a JavaScript library

Access the libraries via the "Edit / JS Libraries" menu item.

If you edit the file using an external text editor, use the 'Reload' button to reload the file into the NeoLoad interface.

Use the "Compile" button to compile your JavaScript libraries prior to execution. Compiling will check the script syntax (missing parentheses...) but not its validity (call method names ...).

API overview

This section gives an overview of the NeoLoad API. Please refer to the API documentation for more detailed information.

Execution context

NeoLoad provides an execution context for each script in order to manipulate variables, errors and cookies: the pre-defined context variable which allows procedures to be carried out on the Virtual User being run.

Please see the documentation for the API RuntimeContext object.

Variable management

NeoLoad features a Variable Manager, which allows the user to retrieve the value of a variable, create a new variable, or increment the value of a variable defined in NeoLoad. The Variable Manager is accessed via the context.variableManager context.

For example, the script below retrieves the value of a NeoLoad variable, changes the value, and uses the new value to create a new variable. This new variable may now be integrated into the Virtual User's actions, for example inserted in a form.

var varMng = context.variableManager;
var searchID = varMng.getValue("searchID");
varMng.setValue("newSearchID",parseInt(searchID)+1);

Please see the documentation for the API VariableManager object.

Logger

You may use the logger to record events linked to the execution of a script. It will write both to the Load Injector's log file ("loadGenerator.log.00x" of the logs folder. Open the logs folder with the menu "Help / open logs folder") and to the NeoLoad interface in the case of an error. They are classified in 5 levels of importance:

  • FATAL

  • ERROR

  • WARN

  • INFO

  • DEBUG

You may set the maximum level to be used in the project's preferences:

In Virtual User validation mode, the DEBUG level is selected automatically.

The example below is a script writing an error message to the logs.

logger.error("Invalid value: "+myvar);

Please see the documentation for the API Logger object.

Error management

When execution a JavaScript script, it is possible both to error flag the action and stop its execution. The error is then displayed in the test results. The error contains the error message and the logs corresponding to the level selected.

The example below is a script flagging an action as an error.

context.currentVU.fail("Invalid value: "+myvar);

Please see the documentation for the API VirtualUser object.

Adding a cookie

The API also allows the user to add a cookie for a given server while a Virtual User is running.

Please see the documentation for the API VirtualUser object.

Script example
var varMng = context.variableManager;
// Retrieves the searchID variable extracted from a request preceding this JavaScript
var searchID = varMng.getValue("searchID");
// Log the searchID value in debug mode
logger.debug("searchID="+searchID);

// Error management if searchID variable is missing
if(!searchID) {
  // Stop script execution and prompt the NeoLoad error
  context.fail("variable SearchID not found");
}

// Create a new cookie for server 'myServer_80'
context.currentVU.setCookieForServer(
	"myServer_80",
	"cookieName="+searchID+"; Expires=Sat, 30-Sep-2006 21:03:07 GMT; path=/"
);

// Create a new runtime variable named 'newSearchID'
// Note: all NeoLoad variables are character strings, 
// they may need to be converted using the following
// methods parseInt(), parseFloat(),...
var newSearchID = parseInt(searchID)+1;
varMng.setValue("newSearchID",newSearchID);
Java Libraries

NeoLoad allows you to use Java classes and methods in JavaScript actions. To use a Java library, simply copy the .JAR files into the <neoload-project>/lib/jslib directory. The added files will be automatically taken into account.

The class names must be fully qualified within the JavaScript, (even for the Java classes like java.util.List) and preceded by "Packages.".

For example:

var myObj = new Packages.com.company.MyClass();
var result = myObj.compute(myArg);
var result2 = Packages.com.company.MyClass.someStaticMethod(result);

RendezVous

Using rendezvous points

NeoLoad allows you to test your web application's response times under specific loads.

Rendezvous points are used to synchronize a number of virtual users to carry out the same task at precisely the same moment, in order to create an intense load on the server at a specific point in the application being tested.

About rendezvous

When running a test scenario, it can be useful to ensure that a certain number of virtual users carry out certain tasks simultaneously. This can be done using rendezvous points. A rendezvous point allows you to create a specific load spike at a given point in the virtual user's execution.

For example, in a web application for managing bank accounts, you might want to assess its performance when ten users simultaneously check their account balance. To simulate this functional case, you must force the virtual users to carry out the task at exactly the same time.

A rendezvous works a little like the line at a fairground ride:

  • Users enter the line and wait their turn. While they're in the line, they're not using the other rides.

  • When a car arrives, it relieves the line of a number of users equal to the car's capacity. It's what is known as the release policy.

  • If the car takes too long to arrive, users will leave the line. This is a timeout.

Creating a rendezvous

To create a rendezvous, you need to have read and understood the following:

To create a rendezvous point:

  1. Go the "Virtual Users" tab in the "Design" section.

  2. Right-click on the virtual user or container into which you want to insert the rendezvous.

  3. Select "Insert in", then "Rendezvous".

Defining the attributes of a rendezvous action

A rendezvous action has the following attributes:

  • Name: identifies the rendezvous specified by the action.

  • Description: completes the rendezvous definition, for information purposes.

A rendezvous point is identified by its name. Several RendezVous logical actions may use the same rendezvous point and for that, they must use the same name.

Once the rendezvous points have been configured, you must configure the rendezvous's behavior when the scenario is run.

Configuring a scenario's rendezvous

Overview

A rendezvous' behavior is configured for each scenario. Its attributes are:

  • A state: enabled or disabled. A rendezvous may be enabled/disabled.

  • A release policy: defines the condition to be met before the users arrived at the rendezvous are released

There is a one-to-one relationship between a rendezvous point's name and a rendezvous. Each unique rendezvous action name corresponds to one rendezvous.

Enabling/disabling a rendezvous

To enable or disable a rendezvous:

  1. Go to the project's "Runtime" section, on "Scenarios" tab.

  2. Select the scenario to be changed.

  3. Click "Advanced...".

  4. In the displayed window, select "Rendezvous policy".

  5. In the list of rendezvous, check or un-check the rendezvous to enable or disable it.

Alternatively:

  1. Go to the project's "Design" section, on "Virtual Users" tab.

  2. Select the rendezvous action you want to use.

  3. Click on the blue link "Edit the scenario's rendezvous policy".

  4. If the project contains several scenarios, select the scenario you want to change and click "OK".

  5. In the list of rendezvous, check or un-check the rendezvous to enable or disable it.

[Note]Note

If NeoLoad displays a warning that the rendezvous is not associated with the selected scenario, it means that the virtual user containing the rendezvous is not in one of the populations linked with the scenario.

A scenario contains populations; populations contain virtual users; a virtual user contains rendezvous points.

Defining a rendezvous' release policy

A release policy is defined according to the following attributes:

  • A Release Condition: the condition that must be met before the users arrived at a rendezvous are released.

  • A Timeout: the maximum wait time between two consecutive users arriving at the rendezvous. If no user arrives at the rendezvous within that time period, all the users arrived at the rendezvous are released. The timeout is expressed in seconds.

    [Note]Note

    The timeout is local to the load generator. When a rendezvous on a load generator times out, only the users arrived at the rendezvous on that load generator will be released. Other load generators with users arrived at the same rendezvous are not affected.

The following release conditions can be set:

  • Release when XX% of the users have arrived at the rendezvous: XX is the ratio of the number of users arrived at the rendezvous against the number of users currently being executed and eligible for the rendezvous. A user is eligible for the rendezvous if its execution chain contains a rendezvous point with the same name as the rendezvous.

  • Release when XX users have arrived at the rendezvous: XX is a fixed number of users.

  • Release manually: When this option is selected, you will need to release the virtual users using JavaScript actions. For more information, see the documentation on the rendezvous JavaScript API.

    [Note]Note

    Fulfillment of the release condition is based on the overall state of the test's rendezvous also when several load generators are used.

    For example, a test includes a rendezvous that releases when 100 users have arrived, and the scenario is being run using two load generators, LG1 and LG2. LG1 and LG2 have 30 and 70 arrived users respectively. The condition is fulfilled, since 30 + 70 = 100. The controller will send a release order to each of the load generators. So, there will be a total of 100 users released, spread across the two load generators.

Frequently-asked questions
How are the released users allocated?

When the controller decides to release users from a rendezvous, it dispatches the number of users to be released equally between load generators, based on their current load.

Several users have the same rendezvous (rendezvous points with the same name). How are the arrived users released?

Each load generator maintains an arrivals list of virtual users for each rendezvous. Several rendezvous points with the same name are considered as being the one and same rendezvous. Therefore, the users are released in the same order as they arrived at the rendezvous.

< Prev Up Next >
Shortcuts Home Populations