15 October 2026, 07:04 PM
How to Calculate Concurrent Users for Website Performance Testing
We tested with 500 users. On launch morning we had roughly 500 users. The system still fell over for twelve minutes.
Same number, completely different shape. The test had ramped up gently over an hour, the way a tidy graph does. The real users all arrived at once, because the product was a business tool and everyone's first act at 9:00 a.m. was to log in. Identity services, session creation and the first heavy dashboard load all took the hit together. By 9:15 the worst was over, and by 9:30 the system looked healthy again. Anyone checking the hourly average afterwards would have wondered what the fuss was about.
I'm describing a composite built from a few launches, so don't go looking for a specific company. But the lesson is general. "How many concurrent users?" is really two questions: how many are in the system at the busiest time, and how fast do they arrive? A good calculation answers both, and the best way to trust it is to get the number more than one way.
So here are three methods, what each is good for, and how to combine them.
The Idea Underneath All of It
Picture a coffee shop. Customers walk in at an average of two per minute, and each stays about ten minutes. How many people are inside at a typical moment? Twenty. You didn't need a headcount. Rate of arrival times length of stay gives you the crowd.
That's Little's Law, and it works for websites, queues, call centers and database connection pools alike:
People in the system = arrival rate × time each one stays
Everything below is an application of that sentence. The three methods differ only in where they get the arrival rate and the time spent.
Method One: Count the User Base
This is the natural starting point for products with accounts, especially internal and B2B tools, where you know exactly how many people could be using the system.
Work down from the licensed or registered base.
- Total users: 20,000 licensed accounts
- Daily active ratio: 35 percent log in on a given working day, giving 7,000
- Peak-hour share: 20 percent of those daily users are active in the busiest hour, giving 1,400
So the estimate is about 1,400 concurrent sessions. Every figure here is an illustrative assumption for the worked example, and the real ones come from your own login and session data. If you have no history, a pilot group, a similar product or a business forecast has to stand in until real data arrives.
The strength of this method is that it's easy to explain to a non-technical stakeholder. Its weakness is that the two ratios are soft. A change from 35 to 45 percent daily activity moves the answer by almost 30 percent, and nobody can prove either number in advance.
Method Two: Count the Sessions
This one uses the coffee shop directly. Pull the number of sessions that started in your busiest hour, and the average session duration.
Say the busiest hour sees 9,000 sessions begin, and the average session lasts nine minutes. Then:
9,000 × 9 ÷ 60 = 1,350 concurrent sessions
The strength is that both inputs are measurable from analytics or logs. The weakness is that averages smooth out skew. A few people who leave a tab open for six hours raise the true concurrency, while a pile of ten-second bounce visits lowers the average duration. If your tool reports percentiles of session length, check them, and consider modeling short and long sessions as separate groups.
Now notice something useful. Method One produced 1,400 and Method Two produced 1,350. They agree to within about four percent. When two independent routes converge, you can be reasonably confident about the order of magnitude. If they'd differed by a factor of three, I'd stop and investigate before running anything, because one set of assumptions is wrong.
Method Three: Work Backward From the Business Task
The first two methods count people. This one starts from what the business needs done, and it's the best way to build the workload mix.
Suppose finance expects the system to process 3,000 invoices per hour at peak. A typical clerk handles about 30 invoices per hour. Then roughly 3,000 ÷ 30 = 100 users will be working in the invoicing workflow at once.
That's not a competitor to the 1,400 figure. It's a slice of it: about 7 percent of the sessions are doing the heaviest transaction, and the rest are browsing reports, searching records and reading dashboards. A realistic test assigns those 1,400 virtual sessions to journeys in proportion. If you modeled all of them as invoice clerks, you'd overload the most expensive path. If you modeled none, you'd skip it.
You can also use this method to sanity check the server side. Those 3,000 invoices might trigger twelve API calls each, which is 36,000 requests an hour, or 10 per second. At 0.4 seconds average per call, about four requests are in flight at any instant. That's the figure your connection pools care about, and it's a lot smaller than anything involving "1,400 users."
The Part Averages Hide: Arrival Shape
Back to the launch story. The hourly figure of 1,400 is an average over the hour. If 40 percent of the day's active users log in within the same ten minutes after 9:00, the login arrival rate is dramatically higher than the average suggests.
Here's the arithmetic with the example's numbers. Daily active users are 7,000. Forty percent of them is 2,800 logins. Packed into ten minutes (600 seconds), that's about 4.7 logins per second. If the same 2,800 logins were spread evenly across the hour, it would be about 0.8 per second. The burst is roughly six times the average.
Two things follow. First, a concurrency number alone can't capture it, so add an explicit arrival-shape test: a ramp that mimics the real morning rush, run on its own, with login and the first heavy page as the focus. Second, think about time zones. A company with offices in several regions gets several smaller storms as each office starts its day, which may overlap with other regions' lunch traffic and batch jobs.
Writing the Assumptions Down
I ask every team to keep the inputs in one small, reviewable file next to the test scripts. It makes the number defensible and makes updates quick when reality shifts. Something like this:
workload_model:
basis: "last 8 weeks of analytics plus product forecast"
licensed_users: 20000
daily_active_ratio: 0.35
peak_hour_share_of_daily: 0.20
sessions_started_peak_hour: 9000
avg_session_minutes: 9
login_storm:
share_of_daily_users: 0.40
window_seconds: 600
journey_mix:
invoicing: 0.07
reporting: 0.40
search_and_browse: 0.45
admin: 0.08
planning_margin: 0.30
scenarios: [low, expected, high]
The point isn't the format. The point is that when somebody asks in three months why you tested at 1,820 sessions, the answer is a file with sources, not a shrug.
Turning the Number Into a Test
A figure like 1,400 isn't a test until you decide how to drive it.
Use an arrival-rate model where your tool supports it, so new sessions keep coming even when the system slows down. Give each virtual user think time, since people pause to read. Without it, virtual users hammer the system far harder than people do, and 1,400 of them can produce many times the real load. Vary the data across users, so caches don't flatter the result. Run low, expected and high versions, and add a stress run above the high case so you learn how the system fails, not only whether it passes. Finally, monitor the load generators themselves, since a starved generator gives you flattering numbers.
When the Estimate Goes Wrong
Some situations break these methods.
Event-driven traffic. If a campaign, a result announcement or a statement release triggers a rush, use the event's own shape and size, not daily averages.
Multi-tenant skew. One large customer might account for a big share of users. Test their usage pattern specifically, because an "average tenant" doesn't exist.
Background activity. Integrations, scheduled reports and syncing mobile apps create load without people behind them. Count them as separate workload types.
Long-lived connections. For real-time features, concurrency means open connections and the memory they hold, which behaves differently from request-based load.
If the Product Has an AI Assistant
Embedded assistants add a layer worth modeling separately. Only a fraction of active users invoke them at any moment, but each invocation can occupy a model for many seconds. Use the same law: in-flight generations equal the arrival rate of requests multiplied by generation time.
Suppose, for illustration, that 10 percent of the 1,400 concurrent sessions ask the assistant something within a given minute. That's 140 requests per minute, about 2.3 per second. If an answer takes 12 seconds to generate, roughly 28 generations are in flight at once. That's the number that matters for model capacity, queueing and provider rate limits, and it's very different from 1,400. Adoption will probably grow after launch, so test a higher scenario too.
AI tools can help with the surrounding analysis, for instance clustering real session paths to build the journey mix, or forecasting from past traffic. The estimate itself still needs inputs you can trace and defend.
Mistakes Worth Avoiding
Quoting one number without a range. Mixing up registered users, daily users and concurrent users. Ignoring the arrival shape and testing only a smooth ramp. Running virtual users without think time. Modeling every session as the same journey. Forgetting that the margin you add for growth should be a conscious decision, not a reflex. And treating the first estimate as permanent, when real production data will soon let you check it.
A Closing Thought
After launch, do one small thing that most teams skip. Compare your pre-launch estimate with what monitoring actually recorded in the first busy week, and write down the differences. Over two or three releases you'll learn which of your assumptions run optimistic and which run cautious, and your next estimate will be better than any formula could make it.
I expect load profiles to keep moving toward replayed production behavior, with real arrival shapes and journey mixes captured automatically. Hand calculation will survive as the sanity check that tells you when the replay looks wrong. If you'd like a second opinion on sizing realistic Concurrent Users for Performance Testing, our team at PrimeQA Solutions can work through it with you using your own analytics.