Load testing an HTTP request
An HTTP request node can send its request many times over, on a profile of requests per second, many at once — and measure what comes back: latency percentiles, errors, the rate it reached. Thresholds decide whether the step passes, and Compare puts the numbers beside an earlier run's.
A load is a setting of the node, not a node of its own: the rest of the experiment — emulators, impairment relays, other branches — runs around it as usual.
Putting a request under load
- Select an HTTP request node and fill in its request.
- In its properties, turn on send under load.
- Choose a Profile and its numbers. The chart under them, Rate over time, draws the rate and says how many requests it adds up to, in how many seconds.
- Set At once — how many requests may be in flight at once.
- Add or change Thresholds.
- Run the experiment.
A load starts as a Ramp from 0 to 100 requests per second over 30 000 ms, 32 at once, with two thresholds: p95 < 500 ms and Errors < 1 %.
Load replaces Repeat and Retry. Turning it on turns them off, and a node with load and either of them is refused (node.load_alone): a failed request is counted, not tried again. Only an HTTP request can run under load (node.load_unsupported).
The request is read once. Its templates are resolved when the step starts, so every request of the load is the same one: {{counter}} and {{uuid}} take one value for all of them. See templates.
One client for the whole load. The requests share the run's cookie jar when Keep cookies between requests is on, and one Digest memory, so one challenge answers them all. Each request has the node's own timeout.
The Inspector gets a sample: at most one exchange every 100 ms, so a load does not flood the Inspector.
Profiles
| Profile | Settings | The rate over time |
|---|---|---|
| Constant | Rate, req/s, Duration, ms | the rate throughout |
| Ramp | From, req/s, To, req/s, Duration, ms | in a straight line from one rate to the other |
| Steps | From, req/s, Step, req/s, Each, ms, Steps | the first rate, then one step more at each level, every level for the same time |
| Spike | Base, req/s, Peak, req/s, Spike at, ms, Spike for, ms, Duration, ms | the base rate, the peak for a while from a given moment, then the base rate again |
| Random | Rate, req/s, Duration, ms | arrivals at random, the rate on average |
Switching the shape keeps what carries over: how long it runs and the highest rate it reaches.
Limits
| Setting | Range |
|---|---|
| Rate, req/s of Constant and Random, Peak, req/s | 0.1–100 000 requests/s |
| From, req/s, To, req/s, Base, req/s | 0–100 000 requests/s |
| Every level of Steps, the last one included | 0–100 000 requests/s; the step may be negative |
| Duration, ms, Each, ms | 100–300 000 ms |
| Steps | 1–100, and all the levels together at most 300 000 ms |
| A spike | longer than 0 ms, and over by the end of the duration |
| At once | 1–512 |
| Thresholds | at most 16, each value a number, 0 or more |
A profile that adds up to no request at all is refused (load.nothing_planned). The rates are those of the HTTP burst.
A profile may last as long as a whole run, 300 s — but the run's time limit counts every step, so leave room for the rest of the experiment.
How many requests
A profile's requests are its rate added up over time:
| Profile | Requests |
|---|---|
| Constant, 100/s for 1000 ms | 100 |
| Ramp, 0 → 100/s over 2000 ms | 100 |
| Steps, from 10/s up by 10/s, 3 levels of 1000 ms | 60 (10 + 20 + 30) |
| Spike, 10/s with 100/s from 1000 ms for 500 ms, 2000 ms in all | 65 |
| Random, 200/s for 10 000 ms | 2000 on average |
The schedule
The n-th request is due at the moment the profile's count reaches n — the first one at once. Every moment is computed from the start of the load, so a late wake-up never shifts the requests after it, and the rate the profile describes is the rate asked for.
Random draws the gaps between arrivals at random, from the run's seed: the same seed gives the same moments, so a random load can be repeated exactly. See seeds.
Missed requests. At most At once requests are in flight. When every one of them is still waiting for its answer, the next request waits for a free slot. If it would go out more than 50 ms after its moment, it is not sent late: it is skipped and counted as missed, with every other request that fell due meanwhile, and the load goes on with the first one still on time. Many missed requests mean the server, or At once, could not keep up with the profile.
While it runs
Once a second the timeline shows the step as Under load, with the seconds gone, the requests sent, the rate over the last second, p95 so far and the failed requests. Stop ends the load at once and drops the requests in flight; a failure in another branch ends it within a second.
What is measured
After the last answer the step has its measurements, kept on its last timeline event and in the run report:
| Measurement | What |
|---|---|
| planned | the requests the profile adds up to (Random: on average) |
| sent | requests that were answered or failed |
| ok | answered with a 2xx status |
| failed | any other status, or no answer at all |
| missed | due while every slot was busy, and skipped |
| rps | requests sent per second: sent ÷ the profile's duration — or ÷ the time until the last request went out, when that was later |
| error_rate | failed, in % of sent |
| min, mean, max | the fastest, the average and the slowest request, ms |
| p50, p90, p95, p99 | the latency that 50, 90, 95 and 99 % of requests were at or under, ms |
| received_bytes | body bytes received in all |
| statuses | requests by status (200, 503) and, without one, by cause (timeout, refused, reset …) |
| seconds | each second of the profile: requests sent, failed, their mean latency |
| histogram | requests by latency, up to 1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000, 5000, 10 000 ms, and slower |
A request's latency runs from sending it to having read its whole answer, and a failed request counts with the time it took to fail. The percentiles are read from logarithmic buckets 1 % wide and are within 0.5 % of the true value, however long the load runs.
Thresholds
A threshold is a row of Metric, Comparison and Value; Threshold adds one.
| Metric | Read in |
|---|---|
| p50, p90, p95, p99 | ms |
| Mean, Slowest | ms |
| Errors | % of the requests sent |
| Rate | requests per second achieved |
| Missed | requests |
Comparison is one of <, ≤, >, ≥. A few common ones:
| Metric | Comparison | Value | The step fails when |
|---|---|---|---|
| p95 | < | 300 | one request in twenty or more took 300 ms or longer |
| Errors | < | 1 | 1 % or more of the requests failed |
| Rate | ≥ | 180 | the server could not take 180 requests a second |
| Missed | ≤ | 0 | a single request had to be skipped |
In a file a threshold is { "metric": "p95_ms", "op": "lt", "value": 300 }; the metrics are p50_ms, p90_ms, p95_ms, p99_ms, mean_ms, max_ms, error_rate, rps and missed, the comparisons lt, le, gt and ge.
The thresholds are read after the last answer, in their order. The step fails on the first that does not hold (load.threshold), its message giving the threshold and the value measured, and the run fails with it. Without thresholds a load passes whatever it measured. When another branch's failure ended the load early, that failure is the run's, not a threshold.
The result
When the step passes, the timeline sums it up: the requests, the rate, p95 and the share that failed. Select the node: its properties show Last run's load —
- each threshold, ✓ Held or ✕ Not met, with the value measured;
- Sent, Req/s, Errors with their share, Missed;
- p50, p90, p95, p99, Avg, Max;
- Each second: the requests of each second, the failed ones in red, and their mean latency as a line;
- Latencies: how many requests took how long;
- the statuses and causes, each with its count.
The command line prints the same numbers and each threshold's verdict; see signallab run.
Comparing two runs
- Run the experiment twice, or more.
- In the timeline, press Compare. It is there once a run has saved its report, and is disabled while a run goes.
- The latest run is After, the one before it Before; either list picks another run.
The lists hold the runs of this experiment — by its name — from the reports in the data folder, newest first, at most 50: each with its date and time, how it ended and its seed. Runs from the command line are there too when it used the same data folder. Renaming the experiment starts a new history.
For each load step, matched by node, a table shows every metric Before, After and the Change, in the unit and in %. A change the wrong way by 5 % or more — slower, more errors, more missed requests, a lower rate — is a regression and shows in red; from nothing to something counts too. Under the table, each threshold's verdict in both runs. A load step that only one of the runs has is marked only before or only after, without changes. Runs without load steps show No load steps in these runs.
From a script, experiment_runs lists the runs and experiment_compare compares two, by their report's file name; signallab mcp offers the same to an assistant (MCP).
Checks after a load
A load leaves no response of its own: it is measured, not checked. A check or Extract value after it needs another request without load before it on every path, or the experiment does not run (graph.needs_http). To check one answer of the API under load, put a plain HTTP request after the load, or in a parallel branch beside it.
Send now on a node under load sends its request once.