API performance testing

Use case

API performance testing answers a focused question: can this API handle the expected request shape, at the expected concurrency, without unacceptable latency or error rates?

Unlike browser performance testing or synthetic monitoring, API performance testing targets the HTTP or gRPC surface directly. The scenario is a sequence of requests with realistic payloads, optional authentication headers, and — critically — assertions that verify the response, not just the status code. A test that passes with a 200 but an empty body is not a passing test.

The bar for “acceptable” is concrete: p95 latency below the threshold your team agrees to act on, error rate below an agreed ceiling, and assertion pass rate above an agreed floor. Without those numbers, a run is a data point, not a decision.

How MaxoPerf supports it

MaxoPerf accepts JMeter, Taurus, and Playwright test files so you can author the scenario in the format your team already knows. Each run is associated with a load profile (virtual users, ramp-up, duration, think time) that you define once and reuse across environments.

Results are broken down by label. Labels are the key unit of analysis: they map to individual request types, user journeys, or API versions. When a release changes the latency of /v2/orders/create but not /v2/orders/list, the label breakdown shows that immediately — you do not need to re-read a wall of percentile rows.

Threshold violations are surfaced in the run summary. A run that meets all thresholds moves to “passed”; one that breaches any threshold is “failed” with a reference to the exact label and metric that tripped. That output is machine-readable, so CI pipelines can consume it without screen-scraping.

Managed runner locations mean you can eliminate “it worked on my laptop” from the debrief. The runner executes from the same network path as your production traffic or from the location you specify.

A concrete load profile

A checkout API team at an e-commerce company runs the following profile against their staging environment before every release candidate:

• Target: POST /v2/cart/checkout and GET /v2/orders/:id/status (two labeled steps)
• Load: ramp from 0 to 80 virtual users over 2 minutes, hold for 5 minutes, ramp down 1 minute
• Thresholds: p95 < 300 ms for checkout, p99 < 800 ms for status; error rate < 0.5%; assertion pass rate 100% (response body contains order_id)
• Location: single managed EU-West runner (matching the majority of their user base)
• Cadence: triggered automatically on every release-candidate build via the MaxoPerf API

In a recent release, the label breakdown revealed that p95 for POST /v2/cart/checkout had climbed from 210 ms to 410 ms — breaching the 300 ms threshold. The team traced it to a missing database index introduced in the same branch, reverted the migration, and reran the test before promoting the build.

Practical rollout

1. Write a smoke scenario — one labeled request per endpoint you care about, at 5 virtual users, 60 seconds. Focus on getting assertions right before tuning load.
2. Agree thresholds with stakeholders — p95, error rate, and assertion pass rate for each label. Record them in the run configuration, not in a shared document that drifts.
3. Run the baseline — a passing run at your target concurrency before any changes. Save it with a tag so future runs have a reference point.
4. Wire CI — trigger the scenario on release-candidate builds via the MaxoPerf API. Fail the pipeline on threshold breach, not on run failure alone.
5. Iterate — add labels for newly deployed endpoints, tighten thresholds as the service matures, and promote heavier profiles (soak, stress) when a service is ready.