What Stresix does and does not do

What a run does

A run starts your app on its own server and sends load to it from a second server in the same datacenter. Users are added gradually over the first three quarters of the run, then full load is held until the end. A Standard run reaches 2,500 users over 10 minutes. A Massive run reaches 10,000 users over 15 minutes.

Each user sends the requests you choose (up to 10, in rotation), one after another, as fast as your app answers. A request is a GET path or a full request with a method (GET, POST, PUT, PATCH, DELETE or HEAD), headers and a body. Latency, throughput, errors, CPU and memory are reported every second.

What it does not do

Requests are independent. Values from one response cannot be used in the next, cookies are not kept between requests, and redirects are not followed, so login flows and multi-step journeys are not supported. To test a logged-in API, send a test account token in a header.

WebSocket, gRPC and GraphQL subscriptions are not supported, and custom k6 scripts cannot be uploaded. For those, use k6, Locust or Gatling directly.

Stresix measures what clients see (speed and errors) and what the server does (CPU per core, memory, connections, restarts, out-of-memory kills). It does not see inside your code or your database.

Your app runs as a long-lived container on one server. Serverless behavior such as cold starts, per-request pricing and platform concurrency limits is not measured.

Reading the numbers

Simulated users never pause. Real people read, click and wait, so 2,500 simulated users is closer to a peak-hour crowd than to 2,500 ordinary visitors.

p50 and p95 are estimated from latency buckets and are approximate. A request that takes longer than 10 seconds counts as failed.

The load comes from the same datacenter, so latency does not include the internet between your users and your server.

Errors are HTTP 400 and above, plus connection failures and timeouts. A path that returns 404 counts as an error.

What "no change needed" means

Your setup handled the tested load cleanly on the hardware named in the report. It does not mean it can handle more, or that a smaller server would be enough.

Test what you run

Results describe the setup you tested. If production runs on different hardware or a cluster, test that setup instead.