Load testing in PolyApiIDE starts from the same extension that holds your collections: a load profile, a scenario, percentile metrics and a PDF report you can hand to a client.
There is a wide gap between sending one request by hand and standing up a distributed load generator. Most of the time the question is modest: does this endpoint survive a dozen concurrent users, does latency creep up around the fiftieth request, does the service start returning 429 and 503. None of that justifies new infrastructure.
A load profile defines how the extension repeats a request or a scenario: how many parallel threads, for how long, with what pauses. You are not limited to a single endpoint — a scenario can drive a chain of calls where each step uses data from the previous one.
During the run the extension collects metrics: requests sent, error share, status distribution and latency percentiles. The result exports to a PDF report, deliberately written to be readable by a non-technical recipient, so it can be attached to an email instead of being retold in your own words.
Make sure the request passes by hand first: right address, auth, body. Loading a broken endpoint only produces a flat wall of errors.
Change the environment and the addresses and tokens follow. Running load against production without agreement is rarely worth the alerts and the blocked IP.
Start small — a few parallel threads and a short run — so you have a baseline latency to compare against.
Real traffic is usually a chain: authenticate, create, read, delete. A scenario links the steps, and pre-request and after-response scripts carry values between them — the API is covered in the scripting docs.
Look at p95 and p99 and at the error share rather than the average: that is where you see that some users are already waiting too long. A finished run exports to PDF.
| Task | PolyApiIDE | k6, JMeter, Gatling |
|---|---|---|
| Check an endpoint under tens of parallel requests | Good fit, running within a minute | Overkill for this |
| Drive a multi-step scenario | Good fit | Possible, but needs a script and a setup |
| Report for a client | PDF straight from the extension | Assembled separately |
| Hundreds of thousands of requests per second | Not a fit | Exactly their job |
| Distributed load from several machines | Not supported | Standard mode |
| Headless runs in CI | Not supported | Standard mode |
A browser is one machine, one process and an event loop shared with the UI, and over HTTP/1.1 Chrome keeps at most six connections per host. For serious volume use k6 or JMeter: we close the gap between a manual check and a full load rig, we do not replace the rig.
No. Free covers sending requests, collections, environments, scripts and import. Load profiles, scenarios, QA scenarios and PDF reports come with a paid plan — monthly, yearly, or a lifetime licence bought once.
Relative comparisons are reliable: before and after an optimisation, one endpoint against another, latency growth under load. Absolute numbers depend on your machine, network and browser load, so they are not the figures to quote in an SLA.
No, the profiles target HTTP requests. There is a separate WebSocket workspace with a frame log, but holding thousands of concurrent sockets is not a job for a browser extension.
Run parameters, metrics, percentiles and errors, phrased so they make sense without knowing the tool. The report is written for whoever signs off the work, not only for its author.
No. Everything runs inside the Chrome, Edge or Firefox extension — no separate agent and no JVM.