The biggest mistake teams make in load testing happens before a single script is written: they pick the wrong test size. A load test that’s too small gives you false confidence. Everything looks green in your dashboards, but when traffic surges in production, the cracks appear. A load test that’s too big is just as bad. You waste time, money, and infrastructure testing a scenario that never happens, and you end up chasing phantom bottlenecks.
There are plenty of cautionary tales. For example, an enterprise company launched a new product on Black Friday after only testing 500 concurrent users because that “seemed safe.” Within minutes of the promotion going live, traffic surged to 2,500 users and the checkout pipeline collapsed. On the other side of the spectrum, a university insisted on testing its new portal at 1,000 users, even though peak historical traffic had never exceeded 5,000. The result: inflated cloud bills and a wasted month of chasing bottlenecks that would never have been triggered in reality.
Sizing is where the art and science of load testing meet. You need a number that’s big enough to be meaningful, but grounded enough to reflect reality. The problem is that most teams don’t have a neat “concurrent users” figure in their project documents. Many default to a round number like 500, 1,000, or 10,000 simply because it looks authoritative on a slide deck, and that’s not good enough.
In this article, we’ll walk through three proven ways to size your load tests: 1) requirement-driven, 2) transaction-based, and 3) analytics-based. Each one gives you a framework for turning messy or incomplete data into a defensible test size—one that matches production traffic instead of guesswork.
Method 1: Requirement-Driven Sizing
When you’re lucky, your requirements already contain the answer—you just have to read between the lines.
Some scenarios make it obvious. If your company is planning a live-streamed town hall where attendance is mandatory, concurrency equals the headcount. If there are 1,000 employees, you should test for 1,100 concurrent users (the headcount plus a 10% safety buffer). That’s about as straightforward as it gets.
Other events are trickier but still predictable. Take a university course registration system. For most of the year, traffic is steady and modest. But on enrollment day, the system takes a beating. Students rush to grab seats in popular courses, and traffic spikes far above the baseline. If you know there are 10,000 students and experience tells you that 90% of them will hit the system during enrollment, that’s 9,000 concurrent users. Add in behaviors like students enlisting friends or family to log in from multiple devices, and the real concurrency can exceed 100% of the student population. A safe test might size traffic at 200% of the student users.
This plays out in other industries too. Consider a government tax portal in April. The system may have light usage throughout the year, but on filing day, concurrency spikes dramatically. Or look at a concert ticketing platform. For most events, traffic is spread out. But when tickets for a major artist drop at 10:00 AM sharp, every fan hits refresh at the same time (not to mention bots trying to buy tickets, which is an entirely separate thing to account for). These are requirement-driven moments, and your load test needs to be sized accordingly.
Pitfalls: Requirements often underestimate. Stakeholders may lowball participation to stay conservative on budgets, or they may not account for “lurkers” who log in early to secure a spot, or bots. Always question the number, model for surge behavior, and add buffers.
Rule of thumb: Requirement-driven sizing works best when the event is time-bound and predictable, with clear participant counts. In those cases, requirements give you the most defensible baseline.
Method 2: Transaction-Based Sizing
When requirements don’t hand you a number, your business transactions will. Instead of thinking in terms of abstract users, think in terms of actions: orders, signups, payments, uploads, bids.
The math works like this:
- Identify peak transaction volume. Suppose your e-commerce platform processes 1,000 orders on a typical day, but during the holidays, volume spikes 50% to 1,500 orders.
- Find the active window. If most orders happen between 10 AM and 10 PM, that’s a 12-hour window, or ~125 orders per hour.
- Adjust for uneven distribution. Traffic is rarely even. If peak hours are 25% higher, that’s ~160 orders in the busiest hour.
- Translate into concurrency. If it takes a customer five minutes to complete an order, then 160 orders/hour equals 2.67 orders/minute. Multiply by the five-minute duration, and you get ~14 concurrent users actually placing orders.
- Add browsing traffic. Buyers aren’t the whole story. If your analytics show 10 browsers for every one buyer, that’s another 140 concurrent users.
- Add a buffer. With a 25% safety margin, you’re now at ~190 users. You might even want to add a 50% or 100% margin (or even more depending upon variability).
That’s your test size in this example: 190 concurrent users reproducing the busiest, most meaningful transaction patterns your system will see.
This method works well because it ties load directly to business outcomes. You’re not just testing “190 users,” you’re validating the ability to process “160 peak orders/hour plus browsing.” That’s a number stakeholders understand and care about.
Second example: Auction platforms. Suppose you see an average of 10,000 bids per day, with 40% of those clustered in the final two hours of high-profile auctions. That’s 4,000 bids over two hours, or ~2,000/hour. If the average bid takes 30 seconds to place, that’s ~16 concurrent bidding users. But if your ratio of browsing to bidding is 30:1 (common for auction sites), you’ll need to simulate nearly 500 users to reflect the true load. That test size tells you if your system can handle not just the bidding spike, but the crush of browsers watching and refreshing listings.
Seasonality matters too. Retail isn’t the only vertical with peaks. Travel platforms see demand spikes during spring break and holidays. Tax platforms get crushed in April. SaaS onboarding surges when new contracts close. Transaction-based sizing adapts to all of these by tying concurrency back to business-specific events.
Rule of thumb: Use transaction-based sizing when requirements are vague but business metrics are clear. It’s accurate, stakeholder-friendly, and translates directly to outcomes.
Method 3: Analytics-Based Sizing
When requirements are vague and you don’t have transaction data, analytics tools can fill the gap. Google Analytics, Adobe Analytics, or similar platforms give you traffic data that can be translated into concurrency with a little math.
Here’s how:
- Start with peak traffic. Suppose your site saw 50,000 visitors on its busiest day.
- Convert to hourly traffic. Divide by 24 hours = ~2,100 visitors/hour.
- Adjust for spikes. Traffic isn’t flat. Add 50% to account for uneven distribution → ~3,150 visitors/hour.
- Use average session duration. If users spend an average of two minutes on the site, then 3,150 / 60 × 2 = ~105 concurrent users.
- Add buffer. With a 25% margin, you’re looking at ~130 concurrent users.
That’s your test size: 130 users reflecting the heaviest traffic your analytics have seen.
Example: A SaaS company with 500,000 monthly active users. If daily active users are ~10% of that number (50,000), and 20% log in during peak working hours, you’ve got 10,000 users in your busiest window. If average session duration is 15 minutes, that translates into ~2,500 concurrent users to test against.
Accuracy caveats: Analytics are better than logs, but they’re not perfect. Consider:
- Ad blockers can hide some visits.
- Cookie consent banners may cause undercounting if users opt out of tracking.
- Bot traffic can skew numbers upward unless filtered.
Despite those issues, analytics are a solid fallback. They reflect actual user sessions, normalized across devices and locations, and can be segmented by geography or device type if your platform has regional or mobile-heavy traffic.
Rule of thumb: Use analytics-based sizing when business metrics aren’t available, but you do have consistent traffic data. It’s the most practical way to ground tests in reality.
Special Case: Brand-New Applications
What if you’re starting fresh with a brand-new application? You don’t have requirements that define concurrency, transaction history, or analytics data, which is a totally different issue.
The common mistake is to pick a round number like “2,000 concurrent users” because it feels safe. But that number is meaningless if it’s not tied to expected behavior.
A better approach is to project traffic in terms of transactions or sessions. If you expect 200 uploads per hour, size your test to validate that. If you expect 10,000 signups on launch day, convert that into hourly traffic and session duration. Even rough estimates framed this way give you results that can be interpreted in business terms—this is all math that you can model or work out.
Example: Suppose your marketing team projects 5,000 signups during launch week, front-loaded by a big press release. If you assume 60% of those land on day one, that’s 3,000 signups. Spread unevenly, with 40% in the first three hours, that’s ~1,200 signups. If account creation takes three minutes, you’re looking at ~60 concurrent signups. Add browsing and retry traffic, and you might reasonably test for 200–300 concurrent users. That number is grounded in assumptions, but at least they’re explicit, and you can refine them as real data comes in.
Watch out for guessing because managers what to present a certain way. Stakeholders or managers may push for huge round numbers (“Let’s test 50,000 users to show investors we’re ready for scale”). Resist this. Oversized tests don’t build confidence—they create noise and waste. Ground your sizing in projected transactions, even if they’re estimates.
Recap Table: Choosing the Right Method
| Method | When to Use | Strengths | Risks/Pitfalls |
| Requirement-Driven | Predictable, time-bound events | Clear, defensible, easy to calculate | Stakeholder underestimates, conflicts |
| Transaction-Based | Existing apps with clear business data | Ties directly to outcomes, accurate ratios | Requires good metrics, seasonal effects |
| Analytics-Based | Sites with consistent traffic history | Easy to calculate, based on real sessions | Ad blockers, bots, uneven accuracy |
| New Applications | No history or data available | Forces explicit assumptions, future-proof | Risk of guessing |
Closing Thoughts on Properly Sizing Load Tests
The purpose of load testing isn’t to hit a number—it’s to answer a question. Can your system handle the specific behaviors and events that matter to your business?
- If requirements give you direct numbers, use them.
- If not, transactions provide the most accurate, business-friendly anchor.
- If those aren’t available, analytics offer a reliable fallback.
- For brand-new systems, projections beat arbitrary guesses.
And no matter which method you use, always add a buffer. Real traffic is spiky, unpredictable, and rarely aligns with perfect averages.
LoadView helps make each of these sizing strategies practical. With LoadView, you can model not just user counts, but realistic patterns—burst traffic during enrollment, blended browsing and ordering behavior, or global distribution that matches your analytics. That means your test isn’t just a number, it’s a rehearsal for production reality.
Sizing is the first decision in any load test. Get it right, and every result you gather afterward has meaning. Get it wrong, and no amount of scripting or reporting will save you. With the three methods outlined here, you can size your tests with confidence and make sure your performance results actually match the traffic and activity on your website or application.