Posted by: browserup
February 10, 2016

Estimating Concurrent Users for Load Testing With Google Analytics

When load testing, one of the first questions to figure out is how many concurrent users your testing should target for your real-world concurrency tests. Developing an estimate of your site’s maximum concurrent users provides a starting point for defining future performance goals. For a new site, this can be a challenge, but for an existing site, there are many sources of data you can work from to understand your site’s performance target.

If you know how to parse server logs, or have access to someone who can, the most accurate way to determine out your maximum concurrent users is probably to parse the log entries or use a log viewer to figure this out. You can also use Splunk to calculate this number if you’re a Splunk user. Here’s an example.

But, often times a ballpark number is good enough. For that, Google Analytics works just fine.

Peak Concurrent Users

First, let’s look at your peak concurrent users. If you are using Google Analytics, jot down your average session duration. This thumbnail graph can be found on the main dashboard.

Screen Shot 2016-02-01 at 10.17.04 PM

Next, select a full year in the date-selector at the top. Find your heaviest during the year. Select that day and look at the hourly numbers and find the hour with the heaviest traffic and jot down how many users that is.

peakgraph

Session Windows in an Hour

Let’s figure out the proportion of sessions per hour. Assuming a 6 minute session length, this looks like this:

(60 minutes / 6 minute average session length) = 10 sessions per hour

Concurrency

Now let’s take the traffic for our busiest hour and work out how much of that falls into each session-sized window.

4000 hourly users / 10 sessions per hour = 400 concurrent users

That’s pretty good, but those users are not evenly distributed across the busiest hour. We’re really planning for the busiest minute in the hour, because if we undershoot and can’t handle the full weight of the traffic, people arriving during peak traffic could be deprived of our website!

Account for Some Variance

So we need to make allowance for the uneven-ness of traffic during that hour. For our fudge-factor, we’ll say 2x to account for the uneven spread. Based on what we usually see, 1.5x is typical, but 2x is safer. So 1/10 of the hourly load is 400, and we’ll use 800 as our number to ensure we’ve accounted for variance and we know we’re covered.

This concurrent users number provides a starting point from which to reason about your performance goals.

Future-proofing

In physical engineering, engineers plan for 3x the listed max capacity. So an elevator expected to carry a maximum of 3,000 pounds will be tested to 9,000 pounds. If you are growing, 3x or greater might make sense. So remember that this base number is a starting point, and we should scale our goals up or down, as appropriate to the business objectives, targets, and SLA for your website.