Performance tests
A Performance API test puts your API under load: MaxoPerf ramps a target number of virtual users against your scenario and measures throughput, latency percentiles, and error rate as load increases. Most MaxoPerf runs use this test type. It is what people mean by “load test” or “stress test.”
Create a performance test
Section titled “Create a performance test”From Tests → New test, select the Performance API test card, then choose how to author it:
-
Upload script: bring a scenario file for any supported executor: a JMeter
.jmx, a k6 script, a Taurus YAML, a Gatling simulation, a Locustlocustfile.py, and 16 more. MaxoPerf detects the engine from the file. -
Scriptless builder: build one or more HTTP requests in the console. See Scriptless test builders for what the builder supports.
Either path lands on the same authoring page: name, project, scenario/files (or builder), load configuration, and locations.
Load configuration
Section titled “Load configuration”| Setting | What it controls |
|---|---|
| Total virtual users | Concurrent VUs, distributed across all locations according to weight |
| Max VUs per runner | Per-runner cap; MaxoPerf computes the minimum runner count from this |
| Ramp-up (seconds) | Time to linearly increase load from 0 to the target VU count |
| Stop mode | Duration (run for N seconds) or Iterations (run for N request iterations) |
| Duration / Iterations | The corresponding stop value |
Locations and capacity
Section titled “Locations and capacity”Add one or more rows to the location plan. A row is a managed region (cloud provider + region) or a BYOC private datacenter. Each row gets a runner count and a weight. The weight decides how MaxoPerf spreads virtual users across locations. Auto-balance sets runner counts from the total VU target and the max-VUs-per-runner cap.
Failure criteria
Section titled “Failure criteria”Define SLA gates on any run metric (for example p95 latency or error rate), with a comparator and threshold. When a run breaches a criterion, MaxoPerf marks it failed. You can also stop all runners early. The verdict mode controls this: either a breach on any runner fails the run, or all runners must breach.
Each criterion’s label chooses which requests it judges. The default, All labels (stored as
ANY), judges the whole run; pick a request label from the suggestions to gate one endpoint. A
criterion whose label matched no requests shows No data on the run instead of passing silently.
See Failure criteria pass/fail gates.