How to Calculate Concurrent Users in Performance Testing With Google Analytics

Having a tool you can use to gather application analytics can be extremely useful. Metrics like how many users are in your application at a given time, how long they remain there, the path(s) they take, and where these users originate from provide valuable insights. These insights allow you to better understand your audience and make sure their experience is enjoyable. Google Analytics, for example, can be used to collect all of this information.

In this blog, we will walk through how to calculate concurrent users for performance testing using data from Google Analytics. We will explore how to use the Behavior Flow report, where to find the locations of your audience, and show you how to use this data to set up performance tests that best suit your needs.

We will be showing how to use Google Analytics 3. At the time of writing this blog post, GA3 is expected to be deprecated in July 2023 and replaced by Google Analytics 4.

Where to Get Concurrent User Data in Google Analytics

The Audience Tab

Once you have signed in to your Google Analytics 3 account, navigate to Overview under the Audience tab on the left-hand side. You can then change the date range you want to view in the upper right-hand corner.

This page provides you with insights into your application as a whole over the time period you specify. Some of the main insights include:

• Time frame. You can choose to view the graph from a broader monthly view all the way down to a more detailed hourly view, depending on what you are trying to learn.
• Number of users, or who visited your application.
• Number of sessions.
• How many pages a user views per session.
• The average session length.
• Audience demographics: the language, countries, and cities of your users.

In addition to being able to view all of these statistics in Google Analytics, you can export the data as a PDF, Google Sheet, XLSX, or CSV.

Other areas under “Audience” that may be useful to you include Demographics, Geo, Technology, Mobile, and Users Flow.

Under Demographics, you can see a breakdown of your users by age group and gender.

Under Geo, you can see more detail about the languages and locations of your users and analyze the data based on these distinctions. We will dive deeper into this later.

The Technology tab allows you to see what browsers and operating systems your users are on as well as their screen resolution and colors.

The mobile tab also gives you insight into how many of your users are visiting your application from a desktop, mobile, or tablet device and which devices are used most frequently.

Finally, the Users Flow tab shows volumes of traffic coming from different sources (i.e. country, browser, a particular landing page, etc.). This is very similar to the Behavior Flow (found under Behavior > Behavior Flow) that we will discuss later in this blog. Both are useful when examining the traffic patterns of users traveling through your application.

There are other metrics tabs available to you besides Audience including Realtime, Acquisition, Behavior, and Conversions, but we will spend the majority of this article referencing the Audience tab.

How to Calculate Concurrent Users for Performance Testing

Before we get into actually calculating concurrent users in your application, it is important to discuss the difference between peak and average traffic. On average, most applications have a fairly stable amount of traffic that can be easily handled by the application’s normal setup.

During peak events (like Black Friday), though, traffic can become unmanageable quickly. In order to be prepared for both your everyday traffic and these peak events, it is necessary to test your application at both of these volumes.

You can use the metrics found under the Audience > Overview tab to determine the number of users per session that you need to simulate over a particular time interval. The general formula we will use for calculating this is:

Concurrent users = Avg Sessions in an hour x Avg Session Duration (in sec) / 3600

Let us look at some examples:

Number of Concurrent Users for Average Monthly Traffic

In the screenshot above, you can see I set the date range for the month of August (31 days) and during that time period, we had 368,654 sessions and an average session duration of 4 minutes and 22 seconds (262 seconds).

For our formula, we need the average number of sessions in an hour, not for a whole month. Thus we can take the 368,654 sessions and divide that by the 31 days in August and divide that by 24 hours in one day:

368,654 sessions in August / 31 days / 24 hours = 495.5 sessions in an hour on average

Now we can use our formula:

Concurrent users = Avg Sessions in an hour x Avg Session Duration (in sec) / 3600

Concurrent users = 495.5 x  262 / 3600

Concurrent users = 36.06

Another way to approach this is to first calculate the number of sessions one thread can simulate in an hour and then divide your total sessions per hour by that. 

If one session takes 262 seconds to complete and there are 3600 seconds in one hour, then one thread (or user) can simulate 13.74 sessions in an hour. 

3600 seconds in one hour / 262 seconds per session = 13.74 sessions an hour per user

To simulate 495.5 sessions, you’d need 36.06 threads (or concurrent users).

495.5 session in one hour / 13.74 sessions an hour per user = 36.06 concurrent users

Both of these will give you the same answer - approximately 36 concurrent users are needed to simulate the average traffic for an hour in August. 

Number of Concurrent Users for a Peak Event

In the screenshot above, you can see that we had a peak on April 30. At 1 am, there were 3,950 users in our example application. 

Using this data, we see that the average number of sessions per user was 1.44. If there were 3,950 users, then during that hour there were approximately 5,688 sessions.

3,950 users x 1.44 sessions/user = 5,688 sessions in an hour

We see that the average session duration was 3 minutes (180 seconds), so now we can use our formula:

Concurrent users = Avg Sessions in an hour x Avg Session Duration (in sec) / 3600

Concurrent users = 5,688 x 180 / 3600

Concurrent users = 284.4 

This means you would need approximately 285 threads (or concurrent users) to run for an hour to simulate your traffic during this peak time.

How to Use the Behavior Flow Report

In addition to the volume of traffic we discussed in the last section, the flow of your users is extremely important in setting up your load tests. You may find that your average traffic flows through different paths than your peak traffic. How long these users stay on each of the pages within those paths could also change.

In order to learn how your users are moving through your application, you can navigate to the Behavior Flow under the Behavior tab on the left-hand side. 

Here you can see which pages a user started on and where they went from there:

You can click on an individual box and choose to highlight traffic through that page. You can also hover over a box to see the amount of traffic and drop-offs.

These views can help you build realistic user paths that mirror how users move through your application, including which pages they visit in which order and what percentage of users drops off between each step.

Where to Find Location Data

As mentioned previously, in addition to knowing how many users are in your application and what paths they take, it can be helpful to know where these users are coming from. When setting up a load test in BlazeMeter, you can choose engines from various regions around the world, so having those reflect where your actual users are located is important.

To see this data, you can navigate back to the Audience tab and click on Geo > Location. This will provide you with both a map visual and a table of all the locations of your users during your specified date range. 

Bottom Line

Having an analytics tool allows for greater insight into your users and allows you to test and therefore better prepare for how they will use and move through your application in the future. Google Analytics can be extremely useful in developing load tests to best suit your particular application’s needs.

If you can accurately identify average and peak load events, you can alter your development and testing strategies to better meet those needs before you are in a situation where your application gets overloaded.

See how BlazeMeter can help you validate performance at every software delivery stage with massively scalable, open-source-based performance testing. Try BlazeMeter for free today. 

Start Testing Now