# What’s the best way to calculate how many v‑users I need for a load test?

When you create a test scenario in Loadster, the **v-users** number you specify is the total number of *concurrent*
users Loadster should simulate at any given time during the test.

This means that after each v-user finishes an iteration of your script, another v-user takes its place and starts
that same script again. These v-users come and go as long as there’s time remaining in your test.
Therefore the *concurrent* number of v-users at any time is kept constant, but the total number of unique v-users
iterations is always increasing.

Loadster uses the **iterations** counter to show how many total unique v-user iterations have run your script. If
your script involves making a purchase, for example, the **iterations** count will indicate how many total purchases
have been made in the test.

## Estimating V-Users From Iteration Count

Let’s say you want to simulate 100,000 iterations of your script (user journeys, transactions, etc) in a 1-hour period, but you don’t know how many concurrent v-users that will require.

A basic formula for estimating this is:

`ConcurrentUsers = TotalIterations / (EntireTestDuration / ScriptDuration)`

Let’s say each iteration of your script normally takes 67 seconds to run.

If we plug in 100000 for the total number of iterations we desire, 3600 for the number of seconds in a full hour (the test duration), and 67 as the duration of a single iteration of our script, we get:

`1861 = 100000 / (3600 / 67)`

This tells us that 1861 concurrent v-users is a good starting point, if we want to generate approximately 100000 of this script in an hour.

## Trial and Error

This estimate is merely a starting point, though! A bit of trial and error is still required.

When your site is under load, it’s likely it will get slower. This would cause each iteration of your
script to take *longer* than the 67 seconds it takes when the site is not under load. Once each iteration starts
taking longer, the same number of v-users will be able to run fewer iterations in a given time period.

That’s why we recommend a bit of trial and error in addition to estimation.

If you’re preparing to run an extended test, run a few shorter tests first, to make sure you’ve got the iteration rate dialed in and are running with the correct number of v-users to produce the desired outcome.