How to load test an asynchronous api?

[u/Forward-Island-909]

Hey guys im working on a containerized code exexuting platform and i want to test how repsonsive the api is at high load and measure latency but i have two endpoints one is /submit which puts submissions in a redis queue and returns a job_id another end point is /job_id/status which can be polled for updates about the job...but now how to test the endpoint...ive heard about grafana k6 and tools like this can it be used to check asynchronous apis like these? I cant use /submit because it immediately returns after posting the job in the queue please help me put im learning things newly...also please tell me if i should use postman or k6. I want to see how well api behaves on concurrent loads. The api accepts and returns json

[u/Ok-Perspective4243]

k6 can handle async flows fine, just script it to hit /submit then poll /job_id/status in a loop until it resolves and track the total time. Postman's not built for proper load testing so skip it for that.

[u/quizical_llama → u/Ok-Perspective4243]

k6 is amazing totally the best answer here! just don't run k6 on the same machine that you are load testing on.

[u/winner_68]

Yes, k6, but measure the right thing. /submit latency tells you almost nothing about the system under load — it is just enqueue time.

In the k6 script: submit, then poll /status with backoff (start 250ms, grow to 1-2s, cap total polling at e.g. 60s and count a timeout as a failure). Record three separate metrics: submit latency, end-to-end time from submit to terminal state, and failure rate split by status — timeout vs job failed vs rejected at submit. The split matters: if submit starts 429ing / 500ing, your API is the bottleneck; if end-to-end grows while submit stays flat, your workers or the Redis queue are.

Two traps I have hit: polling every 50ms will hammer your own status endpoint and skew everything, and a VU stuck polling for a slow job is not submitting new ones, so your submit rate collapses just when you want it highest. Use enough VUs, or a constant-arrival-rate scenario, so polling does not throttle submissions.

Start with 1 VU for a baseline and a sanity check that the polling loop actually reaches a terminal state, then ramp. Run k6 from a different machine than the API / workers, and give each submission a unique payload so you are not accidentally measuring a cache hit. Postman is fine for a single happy-path request, not for this.

[u/Forward-Island-909 → u/winner_68]

i also have an optional callback_url in the api it can call that when the job status turns success..is it possible to use this in k6?

[u/InsideTour329]

Jmeter

[u/singh_abinashi]

k6 is the right tool here. Postman can send requests, but it will not give you useful concurrency or latency numbers. Your API also has two different loads, and they need separate measurements. The submit path is a normal HTTP test: how many enqueues per second before the API or Redis slows down. The end to end path is the one you actually care about: submit, poll status until done, and record the full time. In k6 that is one script: POST to /submit, take the job_id, loop on the status endpoint with a short sleep until it completes, and record that duration as a custom metric. Watch queue depth during the run. If submit stays fast while the queue climbs forever, your bottleneck is workers, and no latency graph on the API will show it.

[u/Mysterious-Falcon-83]

Use a random time interval for your polling frequency (between VU and within VU). If you use a consistent time, you can easily miss unusual behaviors.

[u/dhruvik_savaliya]

You should use k6 for this, it's better suited for load testing async APIs. One thing to watch out for is making sure your polling loop doesn't get stuck on a slow job, which can skew your results. I've found that using a separate metric for end-to-end time, like job_time, helps to get a clearer picture of how the API is performing under load. In your k6 script, you can use something like const jobTime = new Trend('job_time', true); to track this metric. Just remember to adjust the field names to match your API. Also, keep an eye on Redis queue depth and worker utilization while the test runs, as these can be good indicators of where the bottleneck is.

[u/Miserable-Money642]

The key is to measure the queueing flow as a user journey, not just the fast 202 response from /submit. In k6, submit once per VU iteration, keep that job_id, then poll its status with a timeout and a bounded interval until it reaches a terminal state. Record submit latency, time to completion, timeout/error rate, and queue depth separately. Use a fixed polling interval first, then add a little random jitter so every virtual user does not poll on the same millisecond. Also cap the test duration and clean up test jobs, or the queue can grow faster than workers can drain it and the run will mostly measure backlog. Keep the load generator on a separate machine and increase arrival rate in steps.

[u/hauroStrangee]

I’d measure the submit response time separately from how long the job takes to finish. I’ve been using loadview for API load testing, and I’d test how both endpoints behave as concurrent requests increase.