PerfLoad / HTTP load test
An HTTP Load Testing Tool That Starts From a Request
An HTTP load test does one simple thing: send the same kind of request from many clients at once and record what comes back. The hard parts are describing the request, controlling how much load you apply, and reading the numbers correctly. PerfLoad handles the first two from a curl command and a short form, and this page explains how to think about the third.
Start a Load Test →Runs in Docker — see the installation guide.
What one test consists of
Every PerfLoad test is a request definition plus a load profile, and both are small:
| Setting | What it controls | Default via the runner API |
|---|---|---|
| Virtual users | How many simulated clients send requests at the same time | 10 |
| Duration | How long the users keep sending requests, e.g. 30s or 5m | 30s |
| Iterations | A fixed number of requests instead of a time limit | not set |
| Pause | Seconds each user waits between its own requests | 1 |
| Timeout | How long a request may take before it counts as failed | 30 |
| Validation | Optional check on the response body, by JSON path, XPath, or text | none |
The request itself — method, URL, headers, and body — comes from the curl command you paste, or from the fields in the Dashboard's quick form.
How load is applied
Each virtual user runs a loop: send the request, check the response, wait for the pause, repeat. That is a closed model, which means the request rate isn't set directly; it follows from how fast the server answers. A useful rule of thumb:
requests per second ≈ virtual users / (average response time + pause)With 10 users, a 1-second pause, and 100 ms responses, expect roughly 9 requests per second. Set the pause to 0 and the same 10 users send far more. If the server slows down, throughput drops with it, because users wait for each response before sending the next. Keep this in mind when you compare runs: changing the pause changes the load as much as changing the user count does.
Reading the result
- Percentiles over averages. p95 is the response time that 95% of requests beat; p99 does the same for 99%. They expose slow outliers that an average smooths away.
- Throughput next to latency. Requests per second on its own doesn't tell you whether the server is healthy. Latency climbing while throughput flattens is the usual sign of saturation.
- Failures. Each response is checked for a 2xx status, plus your validation expression if you set one. A 500, a 429 from a rate limiter, and a 404 all count as failures, so an unexpectedly high error rate is often a bad URL or an auth problem, not a slow server.
Compared with other command-line tools
Tools such as ApacheBench (ab), wrk, and hey are lightweight and quick
for a single URL and a flag-driven load level, and they're a good fit for a fast throughput check from a
terminal. PerfLoad is aimed at the layer around that: taking a full request with headers and a body straight
from curl, varying data per request, and keeping each run's results so you can open, compare, and rerun them.
The load itself is generated by k6. If you already know exactly which tool you like for raw throughput, there's no
need to switch; if you keep rebuilding the same command line and losing the output, this is what PerfLoad saves
you from.
An example
An authenticated GET with a per-request query value, so responses aren't all served from one cache entry:
curl 'https://api.example.com/search?q=${random}' \
-H 'Authorization: Bearer YOUR_TOKEN' \
-H 'Accept: application/json'${random} is a built-in PerfLoad variable (a random number from 0 to 999999), resolved for each
request during Run Test. Send it once with Run Single first, then run 5 users for 30 seconds, and scale up once
the numbers look sane.
FAQ
Does PerfLoad support HTTPS and client certificates?
HTTPS URLs work like any other. The runner API also accepts a PEM client certificate and key for mutual TLS.
What's the difference between duration and iterations?
Duration keeps every user sending requests for a set time. Iterations stops after a fixed total number of requests, which is handy when you want the same request count in every run.
Why does my error rate look high on a healthy server?
Check the failing status codes. Anything outside 2xx counts as a failure, including auth errors and rate-limit responses, so a 401 or 429 can inflate the error rate without the server being unhealthy.
Related guides
Send your first concurrent requests
Paste a curl command, set the users, and read p95.
Start a Load Test →