Sessions, arrivals and concurrency
600 sessions over ten minutes does not mean 600 simultaneous users. How sessions, arrival rate and concurrency relate, and how to estimate concurrency.
Sessions, arrival rate and concurrency
| Term | Meaning |
|---|---|
| Session | One execution of a scenario: a simulated visit, not a unique human. |
| Arrival rate | The rate of session starts, for example starts per second. |
| Concurrency | Sessions active at a particular instant. |
| Arrival window | The configured window during which starts are scheduled. |
| Session duration | Time from starting the scenario to its end or last available report. |
| Completion | A recorded execution outcome, which may be successful or failed. |
Estimate active concurrency
600 starts / 600 seconds = 1 start per second
1 start/second × 30 seconds per session ≈ 30 active sessions
If session duration increases to 60 seconds while arrivals remain at one per second, approximately 60 sessions will be active during a stable period. The requested number of sessions has not changed; concurrency increases because each session remains active longer. This estimate assumes steady arrivals and consistent durations, so actual concurrency will vary while traffic builds up and sessions finish.
UserLimit schedules starts
UserLimit follows the selected traffic pattern to schedule session starts throughout the configured arrival window, allowing new sessions to begin while earlier ones are still running. Actual start times can vary, and the report’s Concurrent users chart shows the resulting active sessions rather than an exact timeline of starts.
The arrival window is when sessions start, not the total elapsed run time. Sessions that are still active at its end can continue until they finish or reach their timeout, as described in the run lifecycle guide.
Start shares differ from active shares
Scenario A: 0.5 starts/second × 10 seconds = about 5 active
Scenario B: 0.5 starts/second × 50 seconds = about 25 active
A fifty-fifty share of starts puts about five-sixths of the active sessions in Scenario B under these assumptions. Scenario B also consumes more total session time. With a small number of sessions, the actual mix may differ slightly from your chosen shares.
Understanding the session counts
Completed sessions shows how many sessions reported an outcome, including failures. The failure details and any stop reason help explain differences from the session count you requested. The Concurrent users chart shows how active sessions changed during the test. A run that stopped early may not represent the workload you intended; support can help investigate missing or delayed sessions.
For 600 sessions lasting 30 seconds each, usage is 18,000 Virtual-User seconds, or 5 Virtual-User hours (VUh). Concurrency and elapsed test time do not change that sum if individual session durations stay fixed. More examples are available in usage and billing.