Concurrent tests runs and Browser VU instance allocation

Grafana k6 k6-browser
1

Hi,

I need some help, I looked at the public documentation but I couldn’t find answers to this two questions:

  1. Concurrent test runs — how many test runs can execute simultaneously in one project/org, per tier? Free tier appears to serialise them; the limits page doesn’t mention this dimension at all.
  2. Browser VU instance allocation — are browser VUs scheduled on dedicated load generator instances, or do they share instances with protocol VUs from other scenarios in the same test?

Same script, same target. With 3 browser VUs and no protocol load: sdk_loaded p95 = 582 ms. With 10 browser VUs alongside 90 protocol VUs in one test: 4817 ms. Resource Timing shows the request is issued at 4588 ms while server wait is 5 ms and transfer 17 ms — the browser doesn’t begin fetching for ~4.5 s. Is this expected contention on a shared generator instance, and does a paid tier isolate browser VUs or permit concurrent test runs so load and browser measurement can be separated?

3

Hi mhalty,

Concurrent runs come from a per-plan limit called “concurrent tests”. Your value is under Testing & synthetics > Performance > Settings > Usage > Stack limits, and paid plans get a “Request limit increase” button on the same page.

Browser VUs don’t run on the load generator next to your protocol VUs. Grafana Cloud k6 starts separate Chrome instances, so those 90 protocol VUs aren’t taking CPU from the browsers. Browser VUs may share an instance, though, so 10 browser VUs can end up with less CPU each than 3.

A paid plan doesn’t change that split. What it gives you is the concurrency to run the load and the browser measurement as two separate tests.

5

Thanks! that’s clarifying, and it matches our CPU canary (flat at 94 → 79 ms across both configs), so the browsers were definitely not CPU-starved.

One thing your answer doesn’t explain, though. With browser VU count held constant at 10, removing only the protocol load still halved the result:

  • 10 browser VUs + 90 protocol VUs → sdk_loaded p95 5145–5407 ms
  • 10 browser VUs + 1 protocol VU → 2741 ms
  • 3 browser VUs + 1 protocol VU → 557 ms

Same browser count in the first two, same 4-minute window. If browser VUs run on separate Chrome instances and don’t share CPU with protocol VUs, why would protocol load affect them at all? Resource Timing puts the delay before fetchStart, the request isn’t issued for ~4.5 s, while server wait is 5 ms. Is there anything shared between the protocol scenario and the browsers, network egress, the CDP orchestration in the runner, or metric push, that could delay request initiation?

Update, I ran a new test:

With 3 browser VUs (so minimal browser-on-browser sharing) plus 90 protocol VUs in one test: sdk_loaded p95 1843 ms vs 504 ms for the identical script with the same 3 browser VUs and no protocol load. Resource Timing shows the loader request is issued at 1597 ms vs 146 ms, while its duration is unchanged (91 vs 108 ms) and server wait is 5.7 ms. If browser VUs run as separate Chrome instances and don’t share CPU with protocol VUs, what couples them such that protocol load delays request initiation?