PerfLoad / API load testing

API Load Testing Without Writing a Test Script

Most API load tests start with a chore: write a script, wire up headers and a payload, then work out how to read the output. PerfLoad starts from the request you already have. Point it at a REST or HTTP endpoint, set how many concurrent users you want, and it reports latency, throughput, and error rate.

Runs in Docker on your machine or in your own environment — installation guide.

How it works

1. Describe the request. Paste a curl command (Chrome DevTools and Postman can both export one), or fill in the Dashboard's quick form: method, target URL, headers, and a JSON body.
2. Send it once. Run Single fires one request through the runner and shows the full response, so you know the request is valid before you generate load.
3. Add concurrency. Set virtual users, duration, and the pause between requests. Ramp-up is available in the Workbench.
4. Run and read. The runner executes the test with k6 and you watch latency and success counts live, then keep the run in history.

What you can configure

A varying-payload example

Hitting one cart item a thousand times tells you about one cache entry. This request uses a variable so each call adds a different product:

curl -X POST 'https://api.example.com/cart' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"productId": "${productId}", "qty": 1}'

Define productId as a Sequential variable (101, 102, 103) and each request takes the next value, looping back to the start. Use a Random variable when order shouldn't matter, or the built-ins (${user}, ${iteration}, ${random}) when you just need something unique per request.

Reading the results

• Latency: look at p95 and p99, not just the average. An average of 120 ms can hide a slow tail that real users feel; the percentiles show it. The live chart shows latency across the run.
• Throughput: requests per second the API sustained at that many concurrent users. If it plateaus while latency climbs, you've found a limit.
• Error rate: success and failure counts. Each response is checked for a 2xx status and, if you've set one, your validation expression. A fast API returning the wrong thing isn't a pass.

The same test through the runner API

Everything the UI does goes through the runner's REST API, which is what makes tests scriptable. A run is a single JSON document:

curl -X POST http://localhost:3000/runs \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://api.example.com/cart",
    "method": "POST",
    "headers": { "Authorization": "Bearer YOUR_TOKEN" },
    "body": { "productId": "${productId}", "qty": 1 },
    "users": 10,
    "duration": "30s",
    "pause": 1,
    "variables": {
      "productId": { "type": "sequential", "values": ["101", "102", "103"] }
    }
  }'

The response includes the run's id, which you can poll for status and summary. When you want that on every deploy, see CI/CD load testing.

When this approach fits

It suits teams that need answers about HTTP endpoints without a scripting detour: QA and QE engineers who would rather not maintain a test codebase, developers checking a new endpoint, and DevOps engineers who want the same test to run from a pipeline. It targets HTTP request tests, so protocols like gRPC or WebSockets aren't what it's for, and elaborate scripted flows are better served by k6 itself — see how the two compare.

FAQ

Related guides