How Overestimating Page Load Requirements Can Be Extremely Costly

When it comes to page load requirements, less can be more. 

Essentially, you want to be aware that overestimating your needs for concurrent or

active visitors to a website can impact your bottom line negatively.

Here is what you need to know about what your website can handle and how to more accurately estimate your actual page load needs.

The Differences Between Requests Per Second and Concurrent Users

First, it’s important to know the different between requests per second and concurrent users. You can help determine what kind load requirements you need through understanding these two terms, and calculating your needs through proper load testing.

A concurrent user will emulate the actions of a typical user at a site during a given time. The number of concurrent users indicate how many users are actively using your site at the same time. Even if you have 100,000 visits per month, you might only have a peak of 500 concurrent users during that period, and these represent users who used your site at the same time during peak traffic.

At the same time, multiple concurrent users might not be making very many active requests to your server during this time period, such as when a user is participating in “think time”. The term “think time” basically indicates the moment a user is viewing content that has already been loaded, and thus no longer need to make demands on a server.

To understand requests per second, you might take the example of a user who is looking at a total of 5 different pages on your website with 10 to 15 seconds of “think time” between each page, leading to 5 requests in 50 to 75 seconds. As you can see, handling 500 concurrent users is a lot easier than handling 500 requests per second.

How Many Requests Per Second & Concurrent Users Can Your Site Handle?

One of the key metrics for determining what your website can handle is accurately gauging concurrent users and requests per second, especially at peak usage times. You can then better determine load requirements for your website. However, it can sometimes be difficult to gauge this information from web analytics software alone, even if you can determine how many visitors were on your website on a daily or monthly basis.

In order to calculate how many requests per second and concurrent users, let’s use an example. Let’s say you have 100,000 visitors per month. Assume for simplicity’s sake that visits are spread evenly throughout the month. That would mean 3,333 visitors per day in a 30 day period. You next want to determine when your site is most active, which will depend on the nature of your website. If you divide 3,333 by a half-day (12 hours), you are left with 277 average users per hour. To determine concurrent users, you need to try and gauge how long people are staying on your site, which you can get a better idea from your web analytic tools.

Lets say that each user spends on average 10 minutes on your site. From there, you can determine that within each hour, one user equals 6 visits (or requests) an hour.

Next, use the following formula:

Average Concurrent visitors = Visits per hour / (60 minutes per hour / average visit length)

For this example, your average concurrent user requirement is 277 / (60 / 10) = 46 concurrent users at any given time. This is a big difference from 100,000 visitors per month. It’s still important to determine what a spontaneous concurrent user p

eak time will be, which means you should multiply your 46 concurrent users number by 3 or 6. In the highest peak concurrent user peak scenario, you would have 276 concurrent users to deal with, all of which might be hitting you with a request once every 5 seconds.

Based on this type of information, you can help you better determine your page load requirements and keep your development and server costs in line.

30,000 Active Users is not 30,000 Requests

Lets say for example that you’re running a gym with 30,000 members, but only 7,000 of them are active. You certainly aren’t going build a location that houses even 7,000 members at the same time. This same metaphor can be applied to your load requirements. Some website owners think they need massive load requirements to handle 30,000 active users. But as we saw above the number of requests per second is much smaller than the seemingly massive number of users.

Take for example this blog, which indicates that Tumblr handled 15 billion page views each month and had over 120 million total users registered. At their peak, their request rate was 40,000 requests per second.

That’s a good problem to have! But it takes a long time to reach that level of traffic for most websites and web applications, especially for startups just launching a new product. Don’t waste your money over-engineering your web application servers for overly optimistic numbers of users. Your focus should be on getting the functionality right first so you will have a chance to eventually attract that horde of users!