Load profiles
Each virtual user loops through the selected requests in order. Choose how the number of users changes over the test:
- Fixed: the same number of virtual users for the whole duration.
- Ramp up: start with a few users and ramp to the target over a set time, to find where latency starts climbing.
- Spike: run at a base load, then jump to the full count for a short spike, to see how the API recovers.
- Peak: ramp up, hold at peak for a set time, then finish, the classic shape for a soak at expected peak traffic.
Live metrics and percentiles
While a test runs you see total requests, throughput (requests per second), average response time, error rate and the P50, P90, P95 and P99 latencies, with charts over time. Errors are reported with the request that produced them, so a burst of 429s or 503s is easy to trace. Finished runs are kept in a history, and you can compare two runs side by side, for example before and after a change.
Pass or fail
Set pass criteria next to the load settings, such as p95<500, error-rate<1, throughput>=20, and every run is marked passed or failed, with the measured value beside each condition. Criteria are saved with the run, so the history shows which runs met them. Latencies are in milliseconds, the error rate in percent and throughput in requests per second; you can also use avg, min, max, p50, p90, p99, requests and errors.
The same conditions fail a CI build with the CLI: swc perf <collection> --pass-if "p95<500,error-rate<1" exits with status 1 when one is missed.
Real requests, real variables
Load tests use your saved requests with their auth, headers, bodies and environment variables, and can take a data file: each virtual user uses its own row, so users send different values. Each virtual user keeps its own variable scope and runs the requests' pre-request and test scripts. Because it is the same engine as the Send button and the collection runner, what you test is exactly what your users' clients send.
userId,query
1001,laptop
1002,headphones
1003,usb-c cableWith this file attached, requests like GET {{baseUrl}}/search?q={{query}} with an X-User: {{userId}} header spread across realistic inputs instead of hammering one cached response.
Limits on the hosted service
Load tests run on the Swastik Codes server, so fair-use caps apply. By default a test can use up to 50 virtual users for up to 300 seconds, each user can run one test at a time, and a few tests per minute are allowed. These limits may change. Load tests must target a public address, and certificate checks cannot be disabled for load tests.
Only load test systems you own or are authorised to test. Sending heavy traffic to someone else's API is against our acceptable use policy and, in many places, the law.
How it works
- Open a collection in the app and start a performance test.
- Choose the requests, an environment, the number of virtual users, the duration and the load profile.
- Start the test (free account required) and watch the metrics. Stop early at any time.
When to use a dedicated tool
For tens of thousands of concurrent users, distributed load generation, or load tests checked into CI as code, use a dedicated tool such as k6, Gatling, JMeter or Locust. Swastik Codes is the quick check before you get there: the requests are already written, so a first answer takes minutes.
Frequently asked questions
How many virtual users can I run?
Currently up to 50 virtual users for up to 5 minutes per test on swastik.codes. The caps exist so one test cannot crowd out everyone else.
What do P95 and P99 mean?
They are the response times that 95% and 99% of requests were faster than. They show the slow tail your users actually feel, which averages hide.
Can I load test localhost?
Not from the web app: it runs load tests from our server, which refuses private and loopback addresses. The desktop app runs the virtual users on your own computer, so localhost and your network work there. Or point the web app at a public staging environment.
Do tests and scripts run during a load test?
Yes. Each virtual user runs the pre-request and test scripts of the requests it sends. A sample counts as an error when there is no response, a transport error or an HTTP status of 400 or above. For a detailed record of every assertion, use the collection runner.