Calculate concurrent users for load tests

To calculate concurrent users, multiply the number of sessions in your busiest hour by the average session duration in minutes, then divide by 60. For example, 1,200 sessions per hour with an average session of 5 minutes gives 1,200 x 5 / 60 = 100 concurrent users. This is Little’s Law (users in the system = arrival rate x time in the system), and it gives you the number of virtual users to start a load test with.

Key takeaways

• Concurrent, simultaneous and active users are three different numbers, and mixing them invalidates the test.
• Derive concurrency from real traffic data: sessions, duration and think time.
• Round up and test beyond your estimate. Launch traffic rarely matches the forecast.

What is a concurrent user?

A concurrent user is a user whose session is open at the same moment as others: they have loaded a page, they are reading, clicking or filling in a form, and they will send another request soon. It is like counting the people inside a shop at one moment, not the number who visited during the day.

In load testing, the concurrent user count is what you simulate with virtual users. Getting it right helps you:

• Plan capacity, so you do not over- or under-provision infrastructure.
• Find bottlenecks before real traffic does.
• Spend the test budget well, by testing the load you expect plus a margin instead of a guessed round number.

Concurrent vs. simultaneous vs. active users

These three terms get mixed up constantly, and they differ by an order of magnitude or more for the same site.

Many people use “concurrent users” and “simultaneous users” as synonyms, and for sizing a test that is fine. The distinction that matters is between users and requests. A concurrent user spends most of the session reading, so at any instant only a small fraction of concurrent users have a request in flight. In the worked example below, 160 concurrent users produce only 2 or 3 requests in progress at a time. Tools such as JMeter and LoadFocus count virtual users (concurrent users), so set that number from this calculation and let the think time in the script shape the request rate.

How to calculate concurrent users

Both common formulas are the same law written two ways. Little’s Law says the average number of items in a system equals the arrival rate multiplied by the average time each item spends in it. For a website, the items are sessions:

1. From analytics (hourly data) Concurrent users = (sessions in the peak hour x average session duration in minutes) / 60
2. From an expected arrival rate Concurrent users = new sessions per minute x average session duration in minutes

Use the same time unit for both parts. Sessions per hour divided by 60 gives sessions per minute, which is why the first formula divides by 60.

def calc_concurrent(hourly_sessions, avg_session_min):
    return hourly_sessions * avg_session_min / 60

# 1,200 sessions per hour with 5-minute average sessions
print(calc_concurrent(1200, 5))  # 100.0 concurrent users

Where to find the numbers

Google Analytics 4

Universal Analytics, where the old “Audience > Overview” report lived, stopped processing data on July 1, 2023. In GA4:

1. Open Explore and create a free-form exploration.
2. Add the dimension Hour (or Date + hour to find the single busiest hour across several weeks).
3. Add the metrics Sessions and Average session duration, and optionally Views per session.
4. Sort by sessions to find your peak hour, and note its session count and average duration.

The GA4 Realtime report shows active users over the last 30 minutes. That is a 30-minute window, not an instant, so it overstates concurrency for short sessions; use it as a sanity check rather than as the input.

Server logs and your own metrics

• Count session starts per minute from access logs or your log platform, and measure session length from the first to the last request of each session.
• If your application has sessions server-side, the number of live sessions at a moment is a direct concurrency measurement; log it every minute.

Peak, not average

Plan around the peak period, not the daily average. A site with 24,000 sessions a day might see 2,400 in its busiest hour, which is more than twice the hourly average of 1,000.

Step-by-step calculation example

• Peak hourly sessions: 2,400
• Average session duration: 4 minutes

Concurrent users = 2,400 x 4 / 60 = 160

1. Find the peak hour.
2. Multiply its sessions by the average session duration in minutes.
3. Divide by 60 to turn sessions per hour into sessions per minute.

hourly_sessions = 2400
avg_session = 4  # minutes

concurrent = hourly_sessions * avg_session / 60
print(f"Simulate {concurrent:.0f} users for realistic load.")  # 160

Use the busiest minutes, not only the busiest hour

An hourly figure averages out the bursts inside the hour. If the 2,400 sessions were not spread evenly and 400 of them started in the busiest 5 minutes, the arrival rate in those minutes was 400 / 5 = 80 sessions per minute. With 4-minute sessions that is 80 x 4 = 320 concurrent users, twice the hourly estimate. Campaign emails, push notifications and TV spots create exactly this shape, so for those events calculate from per-minute data, and run a spike test as well as the steady one.

From concurrent users to virtual users and requests per second

The concurrent user count becomes the number of virtual users in your test, but only if the script behaves like a real user. A real user pauses between pages. Take that think time from your analytics: a 4-minute session with 8 page views means about 30 seconds per page (240 / 8).

Without think time, each virtual user fires requests back to back, and 160 virtual users generate far more traffic than 160 real visitors. With it, the request rate follows from Little’s Law again:

• Page views per second = virtual users / (think time + response time) = 160 / (30 + 0.5) = about 5.2 per second, with a 0.5-second response time.
• Requests in flight at any instant = request rate x response time = 5.2 x 0.5 = about 2.6.

So 160 concurrent users means about 5 page views per second and fewer than 3 requests being processed at once, per page-level request. Each page also loads assets and API calls, so multiply by the requests per page if your test includes them. Our guide to virtual users and requests per second covers this conversion in more detail, and how throughput and response time are related explains why the request rate drops when the server slows down in a test with a fixed number of users. A tool that sends requests at a fixed rate instead, such as Vegeta, keeps sending as the server slows, so the queue and the response times grow the way they would with real visitors.

Advanced considerations

Session duration variability

Little’s Law uses the average session duration, and the average already accounts for the users who stay longer. Using a higher percentile (for example, the 75th percentile session length) does not make the estimate more accurate; it is a deliberate safety margin. If you want a margin, say so and apply it once, not hidden inside the inputs and again at the end.

Peak traffic periods

Sales, launches and campaigns can multiply normal traffic, and the size of the jump varies a lot between sites. Use your own history: compare last year’s sale day or the last campaign with a normal day, and apply that ratio to this year’s forecast. If you have no history, test several levels (for example, 2x and 3x the normal peak) and find out where response times degrade.

Safety margin

Your estimate is a forecast, and launch traffic rarely matches the forecast. Run the main test at the calculated number, then keep increasing the load until response times or errors cross your targets. Knowing the breaking point is more useful than knowing that the site survived exactly the number you guessed.

How to load test concurrent users

Tools

• LoadFocus: runs in the browser with nothing to install, from 25 cloud regions, with no-code tests or your own JMeter and k6 scripts, and live results while the test runs.
• Apache JMeter: free and scriptable; one machine runs out of headroom at some point, so see how many concurrent users JMeter can handle from one machine before planning a large test.
• Gatling: tests written in code, with Java and JavaScript/TypeScript SDKs.
• k6: tests written in JavaScript, run from the command line or Grafana Cloud k6.

Whatever the tool, ramp up to the target instead of starting every virtual user at once; setting the ramp-up period explains how to choose it.

Running a basic concurrent user test in LoadFocus

1. Create a new test in LoadFocus load testing, or upload an existing script on the JMeter load testing page.
2. Pick the test location (one or more cloud regions).
3. Under test configuration, set Virtual Users to your calculated number (for example 160), choose a Duration or a number of iterations, and set Ramp Up Time and Ramp Up Steps.
4. Add the URLs to request, in the order a user visits them, with the HTTP method for each.
5. Run the test and watch response times, throughput, percentiles and errors live; the error charts show how many virtual users were running when each error appeared.

Paid plans scale from 250 to 20,000 concurrent virtual users per test, and the free plan runs tests with up to 10 (loadfocus.com/load-testing, October 2026).

Tips for different readers

• Business owners: ask for the peak-hour sessions and session length from your analytics, and agree on how far beyond that the test should go before a launch.
• Engineers and DevOps: automate a short concurrency test in your CI/CD pipeline with pass/fail thresholds, and keep the full peak test for releases and events.
• Students and product owners: start with the formula on last month’s data, run a small test, and compare the request rate the test produced with what your server logs show for real traffic.

Conclusion

Calculating concurrent users takes three numbers: peak sessions, session duration and think time. Use the busiest hour (or the busiest minutes for campaigns), apply Little’s Law, add your think time to the script, then test at and above the estimate until you find where the system starts to slow down.

Frequently Asked Questions

What is a concurrent user?

A concurrent user is a user whose session is open at the same time as others, whether they are clicking or reading. It is the number of people “in the shop” at one moment, as opposed to the number who visited during the day.

How do you calculate concurrent users?

Multiply the sessions in your busiest hour by the average session duration in minutes and divide by 60. For example, 2,400 sessions per hour with 4-minute sessions gives 2,400 x 4 / 60 = 160 concurrent users. For bursty traffic, do the same calculation with per-minute data from the busiest minutes.

What is meant by concurrent use?

Concurrent use means several users or sessions overlapping in time. It describes the load at a moment, unlike total visits, which add up over a period.

What does per concurrent user mean?

It is a way of counting for limits or pricing: a product licensed “per concurrent user” limits how many people can use it at the same time, not how many accounts exist. Load testing tools often size their plans the same way, by the number of concurrent virtual users per test.

What is the difference between concurrent users and active users?

Active users (daily, weekly or monthly) count unique people over a period. Concurrent users count sessions open at one moment. A site with 20,000 daily active users might have only a few hundred concurrent users at its peak, depending on session length and how traffic spreads over the day.

What is the difference between concurrent users and simultaneous users?

For sizing a load test, many people treat them as the same thing. Where a distinction is made, simultaneous usually means requests hitting the server at the same instant. That number is much smaller than concurrent users, because most users are reading between requests: 160 concurrent users with 30 seconds of think time produce only 2 or 3 requests in progress at a time when responses take half a second.

What is the risk of allowing concurrent sessions?

In security terms, allowing one account to be logged in from several places at once makes account sharing and a stolen session harder to notice. In capacity terms, every open session can hold memory, connections or locks on the server, so more concurrent sessions than you planned for lead to slower responses, timeouts and errors.

How many concurrent users can my website handle?

There is no general ratio that answers it; it depends on your code, infrastructure and what users do. Calculate the concurrency you expect from your analytics, then run a load test that ramps beyond that number and watch where response times and error rates cross your targets. That point is your current capacity.

How many concurrent requests can Chrome handle?

Chromium-based browsers open at most 6 HTTP/1.1 connections per host. Over HTTP/2, many requests share one connection, and the server sets how many streams can run at once; the HTTP/2 specification recommends allowing at least 100.

What happens when too many people are on a website?

The server’s threads, connections or database pool fill up, requests start to queue, response times rise, and then errors appear, usually timeouts and 5xx responses. If the load keeps growing, the service can stop responding altogether until load drops or capacity is added.

Sources

• Little’s Law: J. D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research 9(3), 1961, doi.org/10.1287/opre.9.3.383
• GA4 dimensions and metrics (Hour, Date + hour, Sessions, Average session duration, Views per session): Google Analytics Data API schema (checked October 2026)
• Universal Analytics stopped processing data on July 1, 2023: Google Analytics Help
• Chromium’s 6 connections per host: chromium.googlesource.com, net/socket/client_socket_pool_manager.cc (checked October 2026)
• HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS, “no smaller than 100”: RFC 9113, section 6.5.2
• Gatling SDK languages: docs.gatling.io (checked October 2026)
• LoadFocus test configuration and virtual user limits: loadfocus.com/docs/guides/load-testing/how-to-run-new-load-test and loadfocus.com/load-testing (checked October 2026)

Related reading

• Realistic Load Testing Scenarios for E-Commerce
• What is Concurrency Testing in Software Testing?
• Measure the Right Key Metrics in Performance Testing