Load Model & Traffic Shape
What Is a Virtual User (VU)?
A virtual user is a simulated client that runs a test scenario end to end, independently and in parallel with every other virtual user in a test.
Also known as: VU, VUs, Virtual User
How virtual users work
A load generator creates a pool of virtual users and hands each one a copy of the scenario — the ordered list of requests that represents a single user journey. Each VU walks its own copy of that script: it opens its own connection, keeps its own cookies and extracted variables, and only moves to the next step once the previous one has returned.
Because every VU holds independent state, they are safe to run in parallel. Ten thousand VUs executing a five-step login flow produce ten thousand independent sessions, not one session hit ten thousand times. That independence is what makes a load test resemble real traffic instead of a benchmark loop.
- Each VU has its own cookie jar, so sessions never bleed between users.
- Each VU has its own variable scope — a token extracted in step 2 is visible only to that VU in step 3.
- A VU is synchronous within itself and asynchronous with every other VU, so one slow user does not block the rest.
A virtual user is not a real user
A VU is a worker, not a person. A pool of 500 VUs with no think time will hit a system far harder than 500 real people browsing, because real people read, hesitate, and idle. In the other direction, 500 VUs may stand in for several thousand real daily users, since each VU completes many journeys over the course of a run.
Copying your daily-active-user count straight into a virtual-user setting is the most common way to build a test that measures nothing useful. The number you want is derived from throughput, not from headcount.
Choosing a virtual user count
Work backwards from the rate you need to reproduce. If production peaks at 300 requests per second and one journey costs roughly 2 seconds of server time plus 3 seconds of think time, each VU completes a journey about every 5 seconds — so reproducing that peak takes on the order of 300 × 5 = 1,500 VUs.
Then stop estimating and measure. Run a ramp-up and watch the point where achieved throughput stops tracking the rising VU count. That divergence is the saturation point, and it is a far more honest answer than any arithmetic.