Skip to content
MaxoPerf MaxoPerf docs

RPS-controlled throughput test

Problem: You want to drive a precise number of requests per second (RPS) at your service, not just “n virtual users”, because your SLO is stated in RPS and you want to control throughput independently of response time. You also want to be able to dial RPS up or down live without stopping the run.

Test type: Load test — open workload model.

Prerequisites

Section titled “Prerequisites”

Open vs closed: why it matters for RPS

Section titled “Open vs closed: why it matters for RPS”

A closed workload (the default in most tools) drives a fixed number of VUs. When the server slows down, each VU waits longer, so throughput drops. The server appears healthy even while it is under stress.

An open workload drives a fixed arrival rate (RPS). When the server slows down, queue depth grows, latency climbs, and errors appear — which is what happens to real users. Use the open model when your SLO is stated in RPS or when you are measuring at a service boundary.

Step by step in MaxoPerf

Section titled “Step by step in MaxoPerf”

1. Write the Taurus scenario with throughput

Section titled “1. Write the Taurus scenario with throughput”
execution:
  - scenario: rps-test
    throughput: 200        # target RPS
    concurrency: 500       # ceiling: max in-flight VUs
    ramp-up: 3m
    hold-for: 10m


scenarios:
  rps-test:
    requests:
      - label: GET /api/products
        url: https://api.example.com/api/products
        method: GET
        headers:
          Authorization: Bearer ${API_TOKEN}

The throughput key activates the open workload model in Taurus. concurrency acts as a safety ceiling — if the server becomes so slow that 500 requests are simultaneously in flight, Taurus will not spawn more.

2. Create the test and upload the file

Section titled “2. Create the test and upload the file”
  1. In the MaxoPerf console go to Tests → New test.
  2. Give the test a name and upload the YAML as the entrypoint.
  3. Bind the API_TOKEN secret under Settings → Secrets.

3. Configure locations and start the run

Section titled “3. Configure locations and start the run”
  1. Open the Configuration tab and select one or more locations.
  2. Click Run now.
  3. Open the run. During ramp-up you will see RPS climbing toward 200.

4. Adjust RPS live

Section titled “4. Adjust RPS live”

MaxoPerf lets you change the target RPS (throughput) while a run is active — no restart required.

  1. With the run open, locate the Live controls panel (top-right of the Overview tab).
  2. Click the Throughput control.
  3. Enter the new RPS value — for example, step it up to 300 to explore headroom or down to 100 to back off.
  4. Confirm. The change takes effect within a few seconds and is reflected in the RPS time-series chart.

Verify

Section titled “Verify”
  • The throughput (RPS) chart in the run overview shows a ramp-up to the target value followed by a flat plateau.
  • The p95 latency chart stays below your SLO for the duration of the plateau.
  • If you raised RPS live, you should see the RPS chart step up at the time you made the change.
  • Error rate stays near zero at the nominal load; errors appear (as expected) if you push beyond capacity.

Variations

Section titled “Variations”
  • Multiple scenarios with independent RPS: split into multiple execution entries each with their own throughput and scenario.
  • RPS per location: MaxoPerf distributes the total throughput across locations proportionally to the weight setting in the Configuration tab.
  • VU (closed model) alongside RPS: run a second execution block without throughput to model a mix of long-session users (closed) and stateless API callers (open).
  • Live VU control: in addition to throughput, you can adjust the VU ceiling live in the same controls panel — see Staged ramp profile.

Where to go next

Section titled “Where to go next”