Running an online business without knowing your website capacity is a sort of like basing what you wear today on yesterday’s weather. You could be fine. But things could also go very wrong.
Misjudging the amount of traffic your site can handle risks leading to downtime on your most business-critical days.
Over 81% of enterprises have downtime costs exceeding $300,000 per hour. And 65% of enterprises need at least an hour to fix a crash, meaning lost orders pile up by the minute.
You also lose potential future customers. 79% of visitors who encounter poor website performance avoid purchasing from that site in the future.
The problem is, it’s easy to overestimate the amount of traffic your site can handle.
If you’re framing your question as “How many visitors can view my site at once?” or “How many concurrent users can my website handle?”, you’re going to be overlooking some key factors.
Let’s look at how the “concurrent users” metric is only half the story and what else you should consider.
Google Analytics and concurrent users
A typical way to define web application capacity is by Number of Concurrent Users. Business managers especially like this metric for what a site can handle. It seems to make intuitive sense. It’s like those signs showing the maximum occupancy of an auditorium.
Google Analytics has a handy report showing the number of simultaneous visitors on your website right now.
Google Analytics shows real-time users on your website under Realtime → Overview
The simultaneous real-time users metric is helpful in that it gives you a rough benchmark. If you haven’t experienced a high-traffic situation, there are articles out there describing how to estimate your maximum concurrent users based on your server processing power. Such methods, though, rely heavily on assumptions of how frequently your average visitor clicks through your site.
If you have experienced a high-traffic situation, you can compare real-time user levels from past sales and note how your website performed at those points. Did everything run smoothly? Did you notice bottlenecks? How much did your site slow down?
But, does that mean your uptime strategy should consist of watching the Google Analytics real-time visitors numbers? And assuming you’ll be okay as long as they’re below past levels?
What concurrent users won't tell you
That’s because there are two critical facts missing from the “concurrent users” picture that determine the health of your website under heavy traffic:
- Not all users, pages and requests are created equal, so
- Distribution of website visitors matters tremendously
Understanding website capacity with an analogy
To illustrate, let’s use the analogy of a restaurant kitchen.
Strictly speaking, a kitchen deals with food orders, not guests in the restaurant. The kitchen can prepare X number of orders at a time. Once it prepares those X orders, it can start with the next batch.
Let’s say the restaurant has a capacity of 500 guests. If there are 500 guests but no one is ordering anything, the kitchen has no problem. If there are 200 guests but all order at the same time, there will be a backlog.
The capacity of the kitchen is tied to the rate at which they can process the orders, not necessarily how many people are in the restaurant.
The different stages of the diners’ meals also require different levels of effort. If I order bread, the kitchen can serve up a pre-sliced breadbasket in no time. But if I order a soufflé, that will require much more kitchen resources to fulfill.
Bottlenecks are where your website breaks down
Just like diners at the restaurant are at different stages of their dinner, your website visitors are at different stages of their purchasing flow. “Active users on site” says nothing about where those users are on your site.
We know that the checkout process, and payment gateway in particular, is a huge bottleneck for transactional websites. Your website could be fine handling 1,000 real-time users if they’re distributed evenly on your site. But if they’re clustered at your payment gateway, your site will crash.
And just like the diners at the restaurant, not all steps in the user journey require the same level of resources.
If I’m a visitor checking out static content, like the Contact Us page, I am putting very little strain on your servers (especially if you cache static content using a CDN, which is an essential tip to building performance into your website).
However, when I’m using dynamic parts of your website, like adding products to my cart, your servers must do the heavy lifting of serving me dynamic content and coordinating with your database and inventory system.
So, analyzing simultaneous users in Google Analytics only gives you a snapshot into the overall picture. Depending on the distribution and behavior of your users, your website could crash far earlier than you’d expect.
Use a flow-based approach to ensure performance
From our decade of experience working with enterprise websites under high visitor load, we’ve seen how critical it is to view website capacity as a flow, instead of a static snapshot.
A website is a system, and we should be thinking of website throughput as opposed to “capacity”. Thus, instead of a raw number of visitors (capacity), you need a rate of visitors per unit of time (throughput).
For optimal performance, your website must have an average inflow equal to the average outflow. If average inflow of visitors to your website is below average outflow, your website’s full capacity is not used. If inflow exceeds outflow, your website will congest.
How the concurrent users metric can mislead you
Let’s say that you’re running a product launch, and that your website has handled about 1,000 concurrent users in the past before you’ve had issues. At 10am, your website visitors will be able to buy your new product, and the time to checkout will be 10 minutes.
If you have 1,000 visitors start their customer journey precisely at 10am, you’ll be fine then, right?
You’re essentially sending a wave of visitors through the journey at the same time, which will overwhelm your bottlenecks. For the system to be stable, the throughput should be 100 visitors per minute with a customer journey of 10 minutes.
Thus, you’ve actually overshot your true capacity tenfold.
How to find your optimal throughput
For sure, the best way to understand your website’s true capacity is to run load testing.
Load testing is a type of performance testing where you send increasing levels of traffic to your site under controlled conditions. Load testing provides data on the traffic levels your website or app can realistically handle. It lets you analyze website response time and robustness, highlighting when, where, and why your site begins to break down. Think of it as a critical dress rehearsal for your major online sales.
Related: Get Started with Less Painful, Almost Free Load Testing
If you can’t do load testing, you should at least ask your payment provider for what their throughput is. Because this is a known bottleneck, you can view the payment throughput as the fastest rate at which your website can handle visitors.
What to do when you know your maximum throughput
A key outcome of the flow-based approach is it highlights the importance of being able to control the inflow to your website.
Our customers do this with our virtual waiting room, which manages all requests to the portions of your website that you protect. Our customers simply enter the throughput rate of their limiting bottleneck (e.g. 100 users per minute) in the admin platform, controlling the rate at which visitors redirect from the online queue.
If you don’t have a virtual waiting room, you could try to coordinate marketing campaigns, for example by sending email blasts out in batches. This would help to avoid bringing everyone to your website at once, though there is nothing to control visitors coming from other sources.
At least, looking at the arrival rate of visitors to your website can help you predict whether you’ll soon run into problems. If you see a sizable increase in the rate of arrival to your website, for example, you can start turning off performance intensive features that aren’t critical to the customer journey.
Related: 11 Essential Steps to Build Performance Into Your Web Application
We’ve covered a lot of ground in this blog post, but at a minimum, here’s what you need to know.
- Maximum “active users” is an incomplete measure of the traffic your website can handle because it doesn’t consider traffic as a flow over time
- Maximum “active users” neglects to tell you anything about the distribution of visitors on your website and whether they are collected at your bottlenecks
- Load testing is a fantastic way to test the flow rate through your website’s visitor journey and identify bottlenecks
- Managing inflow to your website with a virtual waiting room can ensure website performance because you gain control over the distribution and speed of visitors through your website
(This post has been updated since it was originally written in 2014.)