mabl performance tests use existing functional tests in your workspace to simulate load on your application. If you want to try performance testing but don't have the approved services to run load tests against your own company's APIs, you can use the mabl performance sandbox to create and run an API load test.
The mabl performance sandbox is an API that is built to simulate realistic load testing behavior. By default, the performance sandbox returns a 200 response code. You can also add additional parameters that randomly return error responses or add a delay to the response time.
This tutorial illustrates how to create an API load test that uses the mabl performance sandbox.
Add the sandbox application
Before you can create tests using the mabl performance sandbox, you need to add it as an application to your workspace. Go to the applications page to get started: Configuration > Applications.
Create a "Demo" environment
To ensure that your practice tests don't get mixed up with tests in your team's testing workflow, we recommend creating a designated practice environment called "Demo" or something similar.
Create a new application by taking the following steps:
- Click on the + New application button.
- On the new application page, give the application the name "Performance sandbox".
- For the application URL and API URL, enter
http://performance.sandbox.mabl.com
. - Select the "Demo" environment.
- Save your new application.
Create an API test
To run a performance test using the mabl performance sandbox, you must first create an API test:
- Click on the New test button.
- Select API test.
- Give the test a name that is easy to distinguish from others in your workspace, such as "[tutorial] performance sandbox api"
- Associate the test with the "Performance sandbox" application
- Click on the Create test button.
Upon creation, mabl loads the API test editor with https://performance.sandbox.mabl.com
as the api.url
. To simulate realistic load testing behavior, add the following requests to this test:
- A fast endpoint
- An endpoint that returns intermittent errors
- An endpoint that returns intermittent errors with random delays
Request 1: Fast endpoint
Click on the purple plus sign button to add a request and enter the following information:
- Request method: GET
- URL:
{{@api.url}}/fast
-{{@api.url}}
represents the base URLhttps://performance.sandbox.mabl.com
. You can use an arbitrary path, such as/fast
.
Adding the first request in the API Test Editor
Request 2: URL with errors
Use the error
parameter to simulate errors based on frequency. With this parameter, the performance sandbox randomly chooses between a 200 and the listed errors based on the frequency between 0
and 1
. The basic syntax for this parameter is as follows:
error=<code>:<frequency>,<code>:<frequency>
Consider the examples in the following table:
Parameter value | Description |
---|---|
error=500:1 |
The performance sandbox always returns a 500 response. |
error=400:0.05 |
The performance sandbox randomly chooses between returning a 400 response and a 200 response. The 400 response has a 5% chance of being returned; otherwise the performance sandbox returns a 200 response. |
error=404:0.01,429:0.01 |
The performance sandbox randomly chooses between returning a 400, 429, and 200. The 404 and 429 both have a 1% chance of being returned and the 200 is returned otherwise. |
Click on the purple plus sign button to add a new request with the error
parameter:
- Request method: GET
- URL:
{{@api.url}}/flaky
- Query parameter:
error=400:0.01,404:0.05,429:0.03
Adding a flaky request
Request 3: URL with errors and delays
Use the waitrange
parameter to add a delay to the request within a specific range. The basic syntax for the waitrange
parameter is as follows:
waitrange=<sleep milliseconds lower bound>:<sleep milliseconds upper bound>
With this parameter, the performance sandbox randomly adds a delay to the request between the lower bound and the upper bound.
For example, if the waitrange
parameter is set to waitrange=50:200
, the performance sandbox adds a random delay to each request between 50 and 200 milliseconds.
Click on the purple plus sign button to add a new request with the error
and waitrange
parameters:
- Request method: GET
- URL:
{{@api.url}}/slow-and-flaky
- Query parameter:
error=400:0.02,429:0.03,500:0.02
- Query parameter:
waitrange=50:300
Adding a slow and flaky endpoint
Click Save and click on the play button in the top left corner to run your test in the API Test Editor.
Create a performance test
You can now create an API load test using the API test you just saved:
- Click on the New test button.
- Select Performance test.
- Give the test that is easy to distinguish from others in your workspace, such as "[tutorial] performance sandbox api load"
- In the Add functional tests section, click on the + API test button.
- Select the API test that you just created
- In the Application and environment section, select the "Performance sandbox" application, "Demo" environment, and API URL.
- Click Save.
For the sake of simplicity, this tutorial uses the default settings for concurrency and duration and skips failure criteria. To learn more about configuration options for performance tests, including failure criteria, concurrency, and duration, check out the performance testing setup guide.
Run the performance test
To run your performance test, click on the Run test button. Make sure that the test uses the "Performance sandbox" application and the performance sandbox URL: https://performance.sandbox.mabl.com
.
Click Start 1 run to run your API load test!
Review the results
When your API load test has finished running, click on the test status to view the results. Performance test output includes a chart summarizing overall performance metrics and a table with more details about the performance of each endpoint.
Viewing performance test output
For this tutorial, the test output matches the error
and waitrange
parameters configured in the API test. When you start running performance tests on your own application, you can use the approach outlined in our getting started guide to establish a performance baseline.
For more information on reviewing performance test output, check out this guide.