Performance testing SLA Configuration

AgileLoad SLA module and timers

The entry point for the AgileLoad SLA module are the timers (not the page timers). The SLA module will analyse the timers response times and the number of errors which occured between the Start timer and the End Timer statements.

The SLA configuration can be done :

SLA configuration in a job

Select the SLA tab located at the bottom of the job view.

SLA configuration during and after a job execution

The SLA options can be set and modified at any time during and after a job execution. The options are available in the "Global Timer/SLA" view.

  1. Open the Global Timer/SLA view

  2. Select the SLA tab located at the bottom the view

  3. Select the Settings tab located at the middle of the view

When settings are changed, click the button to refresh the SLA status view.

SLA configuration Options

Timer List

The Timer List allows to assign a different SLA criteria to each timer for each load level (number of virtual users).


One column is automatically created for each load level (number of virtual users) (8 users and 16 users on the screenshot above). If the rampup options of the job has been modified, click the button; the column list is automatically modified in order to fit with the ramp-up configuration of the load test.

If several different scripts contain a same timer name, those timers are considered by default as a single timer (the option is selected). If you want to consider them as different timers, unselect the button. Columns which specify the task group and script names are inserted in the list.

If you want to manually add load level columns, click the button. The following dialog appears:

Click the "Add" button to add a new user level. The VU Start level value must be less or equal than the VU End level value. No overlap is allowed between the different virtual user levels specified in the list (eg: on the screenshot below , there is an overlap because VU=8 is specified on line 1 and 2)

Click the "Delete" button to remove a level.

Click the "OK" button; columns are updated in the Timer List.


The timers list is automatically filled with the timers contained in the scripts which compose the job (one line for each timer). Only the timers whose name is constant are taken into account. All other timers must be declared manually in the list.

 If new scripts are added to the job, the list can be refreshed (in order to display the new timers) by clicking the  button.

New timers can be manually added to the list by clicking the button. This is useful if some timer have a name which is not constant (eg: (start timer "Petshop: " + variable).

To remove timers from the list, select them and click the  button.

To modify a timer name, click the timer name in the list.
The timer name can be specified using a regular expression (eg: "petsho.*" : all the timers with a name beginning by the character string "petsho" will be considered as a same timer).

If the option is not selected, the Task and Taskgroup names can also be modified as following:

SLA criterias

A different SLA criteria can be assigned for each virtual user step (columns) and each timer (rows). To modify the SLA criterias, select one (or several) cells in the timer list and modify the thresholds using the options located at the bottom of the view:

Response timer criteria:

To specify a Criteria based on the response time, select the "Timer" option and specify the timer threshold (eg: 60000 milliseconds) and the maximum percentage of timers which must not exceed this response time.

 Transaction error criteria:

To specify a criteria based on the transaction errors, select the "Transaction error" option and specify the maximum percentage of transactions which can fail. 

The right part of the window above allows to define what is a transaction error.

The "Error" options allow to define the criteria which make a transaction to be considered as failed. Those options are :

check if at least one check on a http request located between the start and end timer fails, the transactions is considered as failed.
4XX if at least one http request located between the start and end timer has a 403, 404... response status, the transactions is considered as failed.
5XX if at least one http request located between the start and end timer has a 500, 501... response status, the transactions is considered as failed.
Network If at least one network error occurs on a http request located between the start and end timer, the transactions is considered as failed.

The "Request filter" option allows to do the error controls on all requests or on primary requests only.


Go back to the Learning center:

Copyright © AgileLoad. All rights reserved.
Agile Load testing tool| Contact AgileLoad | Terms of Use | Sitemap