Note
Load-Testing a Mobile Backend With k6 Across Machines
How do you load-test a mobile app's backend with k6 across several machines before a fixed launch date?
Run k6 as an agent on each machine, coordinate them from one controller that splits the target request rate and starts them together, script the real user journey rather than single endpoints, and merge the raw results instead of averaging per-machine summaries. For the Dada Udyogini launch, Shreyansh designed DadaLoad to do exactly that across up to ten Windows machines.
Why one machine isn't enough
A single load generator runs out of CPU, sockets or bandwidth before a real backend does, and then you're measuring the generator. When the launch date is fixed and public — Dada Udyogini's two Flutter apps went live together at a launch event in Maharashtra — the team needs proof of capacity beforehand, not a guess.
DadaLoad's design
- Agents: a .NET Worker Service on each Windows machine that runs k6 locally.
- Controller: an ASP.NET Core service that distributes the target requests-per-second across connected agents and starts and stops them together, over SignalR.
- Journey: a scripted buyer path against the real API — login, browse, product, cart, checkout, order — because the expensive requests are the ones in the middle of a flow.
- Results: live metrics streamed back during the run, and final reports exported as PDF, XLSX and JSON.
Aggregate correctly
The most common mistake with distributed load tests is averaging each machine's p95 latency. Percentiles don't average: the p95 across all requests can be far from the mean of per-machine p95s. Collect raw timings (or mergeable histograms) centrally and compute percentiles once over the whole run.
Make it realistic
- Seed realistic data first — catalogue size and user counts change query plans.
- Add think time between steps so request rates match how people actually use the app.
- Ramp up instead of starting at peak, and hold at the target long enough to see slow leaks.
- Watch the backend's own metrics (database, CPU, queue depth) alongside the client-side numbers.