Menu

Load Testing Basics: How Many Concurrent Users is Enough?

How Many Users Can Your Website Handle?

The most common question regarding a website’s performance is not how fast the website is or how it scales, but something more fundamental:

What should the performance goal be in terms of concurrent users?

Should it be one hundred concurrent users? A thousand? Ten thousand? Does it require one server or a hundred to handle the load?

There’s a good reason for how many times this question comes up: it’s tricky and there’s no definitive answer. If it is a new website it’s anyone’s guess what the demand will be. Even if it is an existing website, web analytics software typically give marketing reports on how many customers were acquired per month or per week, and even a per-day measurement but doesn’t give the numbers required. The reason is the difference between average and instantaneous peak. It doesn’t matter if only 5% of a site’s capacity is used all year if the site was unusable for a critical period. The only thing that matters in terms of protecting your site against crashes and slowdowns is instantaneous peak.

So while marketing speaks in terms of transactions a day or even unique customers on the site, the only measurement useful for capacity planning is how many people were on the website at the same time, the instantaneous peak. By “on the website”, I mean looking at their browsers at a page on the website, regardless of whether that customer is reading or clicking. It’s tempting to use hits/sec or transactions/sec, which are fine metrics, but what happens when you redesign the site for higher performance and the number of hits/sec or transactions/sec drops as a result? The capacity of the site may have gone up, but the number of hits/sec would drop. In the end you need a metric that is implementation independent.

The question of figuring out the maximum number of concurrent users is made even more difficult because a surprising number of people tasked with speccing a website don’t understand the business, and that is critical to increasing the accuracy of the estimate. In the end, it is still a guessing game, not only because of the unknowns, but because it involves the future. Even if you have an existing website with accurate web logs, it’s impossible to tell the future and guarantee that there won’t be a huge traffic spike someday.

So, it is impossible to be really accurate and we’re reduced to being close enough. What are the penalties for getting it wrong? Guess too low, and a site may experience a slowdown or crash during a critical period. Will that merely annoy your customers, or will the company lose money? If it’s the later, then it pays to reduce the chances of a crash happening. But what happens if you over spec a site and there’s too much excess capacity? The downside is added cost and complexity, but that’s the price that needs to be paid for reducing the risk; in this way, building in excess load capacity is like insurance.

Let’s take a look at what the typical systems engineer has in terms of information. If the site exists at least there’s some data, although it almost never has the information that’s actually needed. The information that comes from the site tends to be marketing statistics. That’s nice, but how in the world can you possibly figure out the simultaneous peak user load from that?

Obviously the more information you have about a business the more accurate the guesses, but let’s start with a common situation: the person setting up the website has no idea about the business and no way of getting any information. It sounds strange, but that happens more often that you would believe.

For example, let’s say marketing reports that the site either has or expects to have an average of 150,000 visitors per month. First calculation is easy: figure out the number of visitors per day. If the site is used equally 7 days a week, then divide by 30. If, however, the site is used mostly during the week you’d divide by the number of non-weekend days in a month, around 21.7.

For the sake of simplicity let’s assume the site is used equally throughout the week for a per-day visitor number of 5,000. The next step is to figure out how many hours of the day the site is most active, which will differ from business to business. If you actually know the nature of the business and can identify the peak hours, then by all means, use those, but if you don’t, then figure on using 12 hours as a rule of thumb.

Average visits per hour = (5000 average visitors/day) / 12 hours = 417

To figure out the average concurrent users you need to know the average length a user stays on the site. This can be obtained either from the web metrics, or, if that isn’t available, using a stopwatch and going through a couple of user scenarios yourself on the site, reading all of the material and filling out forms just like a typical user.

Once you know the average visit length, you can then calculate average concurrent users. The key to understanding this calculation is the concept of levels of concurrency. If a user spends on average 10 minutes on a site, then one level of concurrency, i.e. one user simulator could simulate 6 visits in an hour, 60 minutes divided by ten minutes per visit.

Average Concurrent Users = Visits per hour / (60 min/hour / average visit)

Using the 10 minute figure above, with an hourly visit rate of 417 gives an average concurrent user level of just 69, a far cry from the 150,000 per month figure we started with. The math isn’t hard, but it’s faster to type into the online form we use every day at Web Performance, Inc..

Check out this great easy-to-use online calculator:
https://www.webperformance.com/library/tutorials/CalculateNumberOfLoadtestUsers/

Now we know the average number of users on the site at one time, which is useful, but is still short of the number we need to know: the instantaneous peak number of concurrent users. Based on absolutely no science whatsoever, in the load testing business we use a multiplier range from 3 to 6 depending on the accuracy of the average concurrent user number.

The more important it is to your business to not have a slowdown, the higher the multiple. In the above example that would put your “safe” number of concurrent users at 414, the target that would need to be verified by a load test.

As an engineer it bothers me having to guess at these numbers, but then again, guessing is part of engineering. As more websites switch to the automatically scalable architectures enabled by cloud-computing this type of guesswork will be less important. Until then, run these calculations on your own website and let me know how close or how far they come to reality.

Michael Czeiszperger
Founder, Web Performance, Inc.

4 Comments

24 May 2013 10 More Great Web Performance Articles from 2011 » LoadStorm LoadStorm

[…] the folks at Web Performance tackled an age-old question: how do you know many concurrent users to simulate in your tests? Michael Czeiszperger provides […]

24 March 2014 LoadTester01

Hi,

Would you please check here “One user simulator could simulate 6 visits in an hour, 60 minutes divided by six minutes per visit.
Average Concurrent Users = Visits per hour / (60 min/hour / average visit)”

60 minutes divided should be 10 minutes per visit not 6 minutes per visit. And the Average Concurrent Users = 6 / (60/417) = 41.7. Not 69.

Do it make any sense? why just use 417 / 10 = 41.7.

Do I miss something? Look forward for your reply.

Best,
Ken

24 March 2014 Michael Czeiszperger

Thanks for pointing out the typo! The conclusion was correct, but the recap inadvertently said “six” instead of “ten”.

The result is still correct, “one user simulator could simulate 6 visits in an hour”, assuming each visit lasts 10 minutes.

Average concurrent users = 417 / (60m / 10m) = 69.5

Perhaps its easier to push this to the edge case? Say, for example, each visit lasted 1 hour. Thus an average of 417 users in an hour would result:

average concurrent users = 417 / (60m / 60m) = 417.

Using your formula, dividing the average hourly visits by the length of the visit would give 417 / 60m = 7.

Going to the other edge, where each visit lasts a minute would give:

average concurrent users = 417 / (60m / 1m) = 7

Using your formula gives an average concurrent users of 417 / 1m = 417. If the peak visit rate is 417/hour and people only spend 1m on the site how can the average concurrent user level also be 417?

13 June 2014 Testing Magento performance optimization | Plumrocket Inc Blog

[…] Measurements were taken and recorded twice for 10 and 30 concurrent users at a time (which equals to 1000 and 2000 visitors daily respectively). You can calculate your average number of concurrent users on the website by dividing the average number of visitors per hour by average visit time (or check these two tutorials from magemojo and webperformance). […]

Add Your Comment

You must be logged in to post a comment.

Resources

Copyright © 2019 Web Performance, Inc.

A Durham web design company

×

(1) 919-845-7601 9AM-5PM EST

Just complete this form and we will get back to you as soon as possible with a quote. Please note: Technical support questions should be posted to our online support system.

About You
What you Need