Define service level agreements

This task describes how to define service level agreements (SLAs). SLAs measure performance test goals over time intervals during a test run, or over a whole performance test run.

Define SLAs

This section explains the workflow for defining service level agreements.

  1. Prerequisites

    Create a performance test. For details, see Design a performance test.

    Note: To define Average Transaction Response Time or Transaction Response Time Percentile SLAs, your performance test must include a script that contains at least one transaction.

  2. Run through the SLA wizard

    In the Performance Test Designer, click Summary. In the Service Level Agreement pane, click New to open the Service Level Agreement wizard. For user interface details, see Service Level Agreement wizard.

    1. Select a measurement for the SLA.

    2. If you are defining an SLA for Transaction Response Time (Average/ Percentile), select the transactions to include in your goal.

    3. (Optional) When evaluating SLA statuses over a timeline, select a load criterion to take into account and define appropriate load value ranges for the load criterion.

    4. Set thresholds for the measurements.

      • If the values of Transaction Response Time (Average/Percentile) or Errors per Second exceed the defined thresholds, Analysis will produce a Failed SLA status.

      • If the values of Total Hits, Average Hits per Second, Total Throughput, or Average Throughput are lower than the defined threshold, Analysis will produce a Failed SLA status.

  3. Define a tracking period - optional

    For measurements whose SLA statuses are determined over time intervals, you need to define the frequency of the time intervals, known as the tracking period. For details, see Tracking period.

    For user interface details, see Tracking Period dialog box.

  4. Results

    During post test run analysis, LoadRunner Analysis compares the data collected from the test run against the settings defined in the SLAs, and determines SLA statuses which are included in the default Summary Report and the SLA Report.

    To learn more, see Service level agreements overview and the Analysis section of the LoadRunner Help Center.

Back to top

Use-case scenario

This use-case scenario describes how to define a service level agreement (SLA) for Average Transaction Response Time.

  1. Background

    The administrator of Web Tours would like to know when the average transaction response time for booking a flight and searching for a flight exceeds a certain value. Assume that your performance test includes a script that includes the following transactions: book_flight and search_flight.

  2. Start the SLA wizard

    In the Service Level Agreement pane, click New to start the Service Level Agreement wizard. Click Next.

  3. Select the measurement for the SLA

    On the Measurement page, select Transaction Response Time, and from the drop-down list, select Average.

  4. Select the transactions to evaluate in your goal

    On the Transactions page, select the transactions to be evaluated: book_flight and search_flight.

  5. Select a load criterion and define appropriate ranges of load - optional

    On the Load criteria page, select the load criterion to take into account when evaluating the average transaction response time.

    In this case, to see the effect that various quantities of Vusers running on the system has on the average transaction response time of each transaction, in the Load Criterion box, select Running Vusers.

    Then set the value ranges for the running Vusers:

    Consider less than 20 Vusers to be a light load, 20 – 50 Vusers an average load, and 50 Vusers or more a heavy load. Enter these values in the Load Values boxes.

    Note:

    • You can set up to three in-between ranges.

    • Valid load value ranges are consecutive—there are no gaps in the range—and span all values from zero to infinity.

  6. Set thresholds

    On the Thresholds page, you define the acceptable average transaction response times for the transactions, taking into account the defined load criterion.

    In this case, define the same threshold values for both transactions as follows: for a light load, a reasonable average response time can be up to 5 seconds, for an average load, up to 10 seconds, and for a heavy load, up to 15 seconds.

    Tip: To define the same thresholds for all the transactions, enter the values in the Apply to all transactions boxes above the table, and click the Apply to all button.

  7. Define a tracking period - optional

    When SLA statuses for a measurement are determined at time intervals over a timeline, the frequency of the time intervals is determined by the tracking period.

    This step is optional because an internally-calculated tracking period of at least 5 seconds is defined by default. You can change the tracking period in the Tracking Period dialog box:

    1. In the Service Level Agreement pane, click the Tracking Period button.

    2. Select Tracking period of at least X seconds, and select a tracking period. The time intervals are calculated by Analysis according to a built-in algorithm and as a function of the value you enter here.

      Example:  

      If you select a tracking period of 10, and the aggregation granularity for the performance test (defined in Analysis) is 6, then the tracking period is set to the nearest multiple of 6 that is greater than or equal to 10, that is, Tracking Period = 12.

    For details, see Tracking period.

    For user interface details, see Tracking Period dialog box.

  8. Results

    When analyzing your test run, Analysis applies your SLA settings to the default Summary Report and the report is updated to include all the relevant SLA information.

    For example, it displays the worst performing transactions in terms of defined SLAs, how specific transactions performed over set time intervals, and overall SLA statuses.

Back to top