The biggest mistake teams make in load testing often 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 fine in your dashboards, but when traffic surges in production, the cracks appear. A load test that’s too large can be just as unhelpful. You waste time, money, and infrastructure testing a scenario that may never happen, and you can end up chasing bottlenecks that are not relevant to real production traffic.
There are plenty of cautionary examples. For instance, a company might launch a promotion after testing only 500 concurrent users because that number “seemed safe,” only to see traffic surge far beyond that once the campaign goes live. On the other side, a team might insist on testing an exaggerated user count because it sounds impressive, even though historical traffic has never come close to that level. The result is inflated testing costs and time spent optimizing for a scenario that does not reflect reality.
Sizing is where the practical side of load testing matters most. You need a number that is large enough to be meaningful but grounded enough to reflect real user behavior. The problem is that most teams do not have a clean “concurrent users” figure sitting in their project documents. Many default to a round number like 500, 1,000, or 10,000 simply because it looks authoritative in a meeting, and that is not good enough.
In this article, we’ll walk through three proven ways to size your load tests: requirement-driven, transaction-based, and analytics-based. Each one gives you a way to turn messy or incomplete data into a defensible test size 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 them carefully.
Some scenarios make it obvious. If your company is planning a live-streamed town hall where attendance is mandatory, concurrency is closely tied to headcount. If there are 1,000 employees, you might test for 1,100 concurrent users by adding 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 users to plan around. Add in behaviors like students logging in from multiple devices or asking family members to help, and the real traffic can exceed the student population. A safer test may size traffic at 150% to 200% of the expected 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 can spike 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, every fan may hit the site at the same time. Bots and automated purchasing behavior may also add additional load, which should be treated as a separate risk to model.
Pitfalls: Requirements often underestimate real demand. Stakeholders may lowball participation to stay conservative on budgets, or they may not account for users who log in early, retry repeatedly, use multiple devices, or refresh aggressively. 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 give you a number, your business transactions can. Instead of thinking only in terms of abstract users, think in terms of actions: orders, signups, payments, uploads, bids, searches, downloads, or form submissions.
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 about 125 orders per hour.
- Adjust for Uneven Distribution: Traffic is rarely even. If peak hours are 25% higher, that’s about 160 orders in the busiest hour.
- Translate Into Concurrency: If it takes a customer five minutes to complete an order, then 160 orders per hour equals 2.67 orders per minute. Multiply by the five-minute duration, and you get about 14 concurrent users actively 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 about 190 users. Depending on traffic variability, you may want to add a 50% or 100% margin.
That’s your test size in this example: about 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 whether the system can process roughly 160 peak orders per hour plus browsing traffic. That is 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 about 2,000 bids per hour. If the average bid takes 30 seconds to place, that’s roughly 16 concurrent bidding users. But if your ratio of browsing to bidding is 30:1, 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 larger audience 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 heavy traffic in April. SaaS products may see 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 is accurate, stakeholder-friendly, and tied 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, server logs, or similar platforms can provide 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, which equals about 2,100 visitors per hour.
- Adjust for Spikes: Traffic is not flat. Add 50% to account for uneven distribution, giving you about 3,150 visitors per hour.
- Use Average Session Duration: If users spend an average of two minutes on the site, then 3,150 / 60 × 2 = about 105 concurrent users.
- Add a Buffer: With a 25% margin, you’re looking at about 130 concurrent users.
That’s your test size: 130 users reflecting the heaviest traffic your analytics have seen.
Example: A SaaS company has 500,000 monthly active users. If daily active users are about 10% of that number, that’s 50,000 daily active users. If 20% log in during peak working hours, you have 10,000 users in your busiest window. If average session duration is 15 minutes, that can translate into roughly 2,500 concurrent users to test against, depending on how compressed the login window is.
Accuracy Caveats: Analytics are useful, but they are not perfect. Consider:
- Ad Blockers: Some visits may not be tracked.
- Cookie Consent Banners: Traffic may be undercounted if users opt out of tracking.
- Bot Traffic: Automated traffic can skew numbers upward unless filtered.
- Session Duration Issues: Analytics tools may report average session duration in ways that do not perfectly match active user behavior.
Despite those issues, analytics are a solid fallback. They reflect actual user sessions, devices, locations, and traffic patterns, and they can often be segmented by geography, device type, campaign, or landing page.
Rule of Thumb: Use analytics-based sizing when business metrics aren’t available, but you do have consistent traffic data. It is one of the most practical ways 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 creates a different sizing problem.
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 are more useful when they are framed in business terms.
Example: Suppose your marketing team projects 5,000 signups during launch week, front-loaded by a 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 about 1,200 signups. If account creation takes three minutes, you’re looking at about 60 concurrent signups. Add browsing and retry traffic, and you might reasonably test for 200–300 concurrent users. That number is based on assumptions, but at least the assumptions are explicit, and you can refine them as real data comes in.
Watch Out for Guessing Based on Presentation Needs: Stakeholders may push for huge round numbers such as “Let’s test 50,000 users to show investors we’re ready for scale.” Resist this. Oversized tests do not build confidence. They create noise, waste resources, and may send teams chasing unrealistic bottlenecks. Ground your sizing in projected transactions, even if those projections are 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, missed surge behavior |
| Transaction-Based | Existing apps with clear business data | Ties directly to outcomes and transaction volume | Requires good metrics and accurate user behavior assumptions |
| Analytics-Based | Sites with consistent traffic history | Easy to calculate and based on real sessions | Ad blockers, bots, consent gaps, and uneven tracking accuracy |
| New Applications | No history or data available | Forces explicit assumptions | Risk of guessing or using inflated round numbers |
Closing Thoughts on Properly Sizing Load Tests
The purpose of load testing isn’t to hit an impressive number. It is to answer a practical 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 are better than arbitrary guesses.
No matter which method you use, always add a buffer. Real traffic is spiky, unpredictable, and rarely aligns with perfect averages. You should also validate the size against the user journeys that matter most, such as checkout, login, search, registration, payments, uploads, API calls, or dashboard usage.
LoadView helps make each of these sizing strategies practical. With LoadView, you can model not just user counts, but realistic traffic patterns such as burst traffic during enrollment, blended browsing and ordering behavior, global distribution that matches your analytics, or sustained traffic during a major launch. That means your test is not just a number. It is 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 match the real traffic and activity on your website or application.