Concurrent Users: Definition and Formulas

What Are Concurrent Users?

Concurrent users are the number of people actively using your website or application at the same moment in time.

Concurrent users are different from monthly active users (MAU) or even daily active users (DAU). This distinction is important because most reported traffic numbers are cumulative totals in a period.

When it comes to sizing your infrastructure and tuning your application, knowing exactly how many users it needs to handle at the busiest peak time is what matters the most.

Concurrent Users versus Visits, Sessions, RPS, MAU, DAU

The concept of concurrent users is often confused with several related measurements. It’s important to understand which measurement your requirements refer to before you use it to size infrastructure or plan a load test.

Visits and sessions count arrivals during a period of time. A rate of 5,000 sessions per hour tells you how quickly people are arriving, but it doesn’t tell you how many are active at once. It’s kind of like the difference between counting the cars that enter a parking garage during a day and counting the cars currently parked inside it.

Requests per second (RPS) counts the individual HTTP requests reaching your infrastructure. One user might generate a burst of requests when a page loads and then send nothing for a while as they read, scroll, or type. Because of this idle time, 250 concurrent users might produce a small number or hundreds of requests per second, depending on the application and user behavior. There is no fixed conversion between the two, which is why load test scripts need realistic wait times.

Google Analytics “active users” is probably one of the closest analytics equivalents to concurrency. The GA4 Realtime report shows active users over the last 5 and 30 minutes, so it can be a useful live approximation rather than an instantaneous concurrency measurement. Still, keep in mind that some browsers block analytics altogether, and the tool’s approximation might not map to your requirements perfectly.

Calculating Concurrent Users with Little’s Law

You can use Little’s Law from queueing theory to estimate concurrency based on an arrival rate and an average session duration:

ConcurrentUsers = ArrivalRate × AverageSessionDuration

If your site gets 5,000 visits per hour, and an average visit lasts 3 minutes (0.05 hours), then:

250 = 5000 × 0.05

This works out to approximately 250 concurrent users on average at that traffic level. You can use any time unit in the formula as long as the arrival rate and session duration use the same unit. For example, a site receiving 12,000 visits per hour with 90-second sessions (0.025 hours) has approximately 300 concurrent users.

You can apply this same formula at the request level. Concurrent in-flight requests equal requests per second multiplied by average response time. An HTTP API averaging 200 requests per second with an average response time of 500 milliseconds has approximately 100 requests in flight at any moment.

Keep in mind that Little’s Law produces an average for the time period you choose. Even within that time period there will almost certainly be spikes when concurrency is above average.

For capacity planning, use the arrival rate from your busiest period rather than a full-day or even hourly average. A site that averages 1,000 visits per hour over an entire day might easily receive 4,000 visits during its busiest hour. Your infrastructure needs to handle the peak, not the average.

Estimating Concurrent Users From Your Analytics

You can often find both inputs to the formula in your analytics or server logs.

First, find the session count for a recent busy hour and the average session duration during a representative period. In GA4 you can use the sessions metric broken down by hour, or you can calculate arrivals from your server logs. Convert the average duration to hours and then multiply it by the hourly session count to estimate concurrency.

If you’re planning for an event that will be larger than your historical traffic, make sure to replace the historical arrival rate with your forecast while keeping a reasonable session-duration estimate.

You can also compare the result with GA4’s realtime active-users view during a known busy period. The two numbers won’t necessarily match exactly because they use different measurement windows, but the comparison can help you double-check that your estimate is in the right ballpark.

Keep in mind that analytics that include bot traffic might overstate human concurrency, while consent banners and ad blockers might cause analytics to understate it. Treat the result as an estimate and allow some extra headroom for uncertainty.

Concurrent Users in Load Testing

Load testing tools simulate concurrent users with virtual users, or bots as Loadster calls them. Each bot runs through a script independently with its own session and cookies. When you configure a Loadster scenario with 250 bots, you’re simulating 250 concurrent users. Each bot repeats its script while its bot group is running, which keeps the configured level of concurrency steady.

Realistic wait times are important in load test scripts, especially when you’re trying to simulate a specific number of concurrent users. A script with no wait times or pauses performs actions back-to-back, so a relatively small number of wait-free bots might generate the request rate of many more human users. Scripts that simulate people should run at approximately human speed.

For load test sizing, start with your estimated peak concurrency as a baseline and then test beyond it to measure your safety margin. Your exact target should reflect the uncertainty in the traffic forecast and the potentially bad consequences of exceeding capacity in a traffic spike.

How Many Concurrent Users Is a Lot?

The answer depends on the type of site and its traffic patterns. A small business site might peak at a few dozen concurrent users. A busy ecommerce store might run into the thousands during a large sale. One Loadster customer in particular is a large ecommerce brand that runs load tests with over 100,000 concurrent Browser Bots several times a year to prepare for big sales.

Real-world traffic is spiky, and events like ticket releases, major campaigns, and unexpected viral traffic can quickly bring thousands of concurrent users with little warning.

The number of users your site receives is different from the number it can handle. Ideally it should always be able to handle more than it receives, or you’re going to have problems!

Your site’s actual capacity depends on the application, architecture, infrastructure, and caching strategy, so general benchmarks are only rough comparisons. You might want to check out our guide on how many concurrent users your website can handle for how to measure your actual limit with a load test.

By the way, if you’re working backwards from a target transaction count instead of a concurrency number, there’s a separate formula for that.