Getting started with performance tests

From defining expectations to establishing a baseline

Application performance represents an important part of overall quality. When users interact with a slow or unresponsive site, they may develop a negative impression of the brand or organization behind the site or even abandon your application altogether. Performance testing offers a way to monitor your application, prevent poor user experiences, and prepare for seasonal peaks in traffic.

With mabl performance tests, you can use existing functional tests to simulate a load on your application and review the output to ensure your application is meeting users' expectations. This tutorial walks through the basics of mabl performance tests for new users.


Early access program

Performance testing is currently available as an early access program. If you're interested in trying performance testing in early access, you may submit a request here.

Access and pricing is subject to change once the feature is available for general availability. Prior to general availability, changes to performance testing may be made without notice.

Before you start

Before you create your first performance test, discuss the following questions with your team:

  • What tests do we want to use for the performance test?
  • What are our current performance expectations?

Choose functional tests

Mabl performance tests reuse existing functional tests. Before you create a performance test, work with your team to identify which APIs to test.


API tests only

Performance tests are currently available for API tests only.

Select functional tests that validate your APIs in a pre-production or QA environment or APIs in development. By conducting performance tests on your APIs before they are deployed to prod, you can identify issues early and avoid causing performance bottlenecks or failures in your production environment.


Testing in private networks

To test APIs in private environments, add mabl static IP addresses to an allow list. The specific IP range for performance testing is

Mabl Link is not yet supported for performance tests.

Define expectations

Performance expectations can vary depending on the application. Expectations in mabl performance tests are defined by failure criteria.

  • If your application already has clearly defined performance expectations, perhaps in the form of service-level objectives (SLOs), see the performance testing setup guide to learn more about options for failure criteria.
  • If your team has not yet defined performance expectations for your application, you can start by running performance tests without failure criteria to get an idea of how your application is performing.

Create a test

To create your first performance test, take the following steps:

  1. From the mabl home page, click on the New test button in the left-hand navigation.
  2. Select "Performance test."
  3. Give your test a name.


Naming conventions and labels

With your team, discuss what naming conventions and labels you can use to distinguish practice tests from other tests in your workspace. Consider the examples below:

  • Naming conventions: "Walkthrough performance test - Your name"
  • Labels: "tutorial", "walkthrough", or "practice are good labels for distinguishing your practice tests.
  1. Click on the + API test button to add a functional test. For your first performance test, limit the scope to one or a few tests.
  2. Select a test from the dropdown.
  3. Set a concurrency. Concurrency represents the number of virtual users.
  4. Set the duration. Duration represents how long the performance test runs.
  5. Click Save to create the test.


Start small

For your first performance test, choose a low concurrency and duration. For example, set a concurrency of five users and a duration of 15 minutes.

As you understand more about how your application performs under load, you can gradually increase the concurrency in subsequent tests.

For your first performance test, we recommend skipping the failure criteria if your team does not have defined performance SLOs. Once you have an understanding of how your application performs and you've aligned with your team on performance SLOs, you can set failure criteria accordingly.

Setting up a performance test

Setting up a performance test

For more details about performance test setup, check out this guide.

Run the test

On the Test Details page for the new performance test, take the following steps to run the test:

  1. Click the Run test button.
  2. In the ad hoc run panel, select the application associated with your performance test.
  3. Click Start 1 run.

When the test starts running, its status appears below the Start 1 run button. Click on the status to view the Performance Test Output page.

Triggering an ad hoc run of a performance test

Triggering an ad hoc run of a performance test

For more details on running performance tests, check out this guide.

Review the output

Test output for performance tests consists of two sections:

  • A chart showing performance test metrics across the duration of the test.
  • A series of tables with more granular details about each metric.
Performance test output

Performance test output

As you understand more about your application's performance, you can use these metrics to determine failure criteria and identify regressions in performance. For more details on reviewing performance test output, check out this guide.

Next steps

After creating and running your first performance test, share the results with your team to discuss the next best steps. Some ideas for next steps include:

  • Making a plan to scale up concurrency and duration to understand when your API endpoints start to fail.
  • Working with your team to define performance expectations. Use these expectations to set failure criteria.

Once you identify the baseline performance expectations for your application, you can start testing as new changes are introduced to the app to detect performance regressions before they make it to production.

For more information on performance testing, check out this overview.