Getting started with Nouvola DiveCloud: How do I calculate the number of concurrent users to test with?

Posted by on April 3, 2015 6:00pm

First in a series on effectively using Nouvola DiveCloud

bigstock-Old-Style-Faq-66600220_2-879353-edited It can’t be said enough: Performance testing ahead of time will help ensure smooth sailing in real time. But not all tests are created equal. It’s important to not just test, but test smart, so you get accurate results. Some DiveCloud customers have asked us about this, specifically about the best way to calculate concurrent, or simultaneous virtual users to test with during a web performance test. Here, we explain the five simple steps you can take to arrive at a good number.
  1. Monthly visits. You can use Google Analytics or another analytics software to get  your monthly visits. The important thing here, is to get the total number of visits, rather than unique visits. Let’s say your site has 300,000 monthly visits. This is a good start but it doesn’t tell you anything about how traffic was distributed within the month. From there, you’ll need to understand traffic in small time frames. 
  2. Daily visits. Traffic can very a lot day by day, depending on seasonality, business constraints, traffic patterns, etc. and it is really application dependent. In general, traffic won’t be equally distributed within the month. Google Analytics can help you identify your peak traffic days. A good rule of thumb is to divide the number of monthly visits by 10 to obtain your peak daily traffic. Essentially this means that there is a factor of 3 between your peak days and your average days. So for our example we get to 30,000 daily visits for peak days. However, this is still not enough to run your tests.
  3. Hourly visit. Again, it’s important to keep in mind that traffic is distributed unevenly throughout the day. Perhaps everybody arrives to the office at 9 a.m. and logs into the application around the same time. Or maybe there is a crush of traffic on the last day of the month when there are deadlines to send reports by 5 p.m. Or, is there a specific sale that ends at midnight? You get the idea. The distribution of traffic is really application dependent. A good rule of thumb is to divide daily visits by 10 again. So going back to our example, we get 3000 hourly visits for peak hours. But this is still not enough information to run your test
  4. Visit duration (or time on site). Now you need to find out the average time on site, or the visit duration. This is another value that could be found via Google Analytics, but the number is not always reliable because sometimes users leave browser open. There are also plug-ins that can measure “active time on site,” and are a bit more relevant. Let’s assume the average visit duration for this example is 5 minutes.
  5. Concurrent users. If you want to know whether your software can handle a specific level of traffic with some margin, you need to run a load test. In order to run a performance test, you need to know how many concurrent, or simultaneous users to test with. The way to calculate your concurrent users is as follows:
(Hourly visits * visit duration (in seconds)) / 3600
So for our example, 3000*300 / 3600 = 250 concurrent users 

Tip: Give yourself a buffer.  We usually recommend padding the number of concurrent users 20-30% of margins in order to have a good buffer. You don’t want to hit the limits of your capabilities when you have users on the site, but rather be able to rest assured that you can handle peak traffic, then some. So in this case it would be 250 +20% = 300 concurrent users.

If you expect substantial growth during the next few months, you may want to factor that in with an even bigger buffer.

Now you’re ready to run a performance test. Testing can not only tell you if you’ll be able to serve all of your requests, but also provide a sense of how long this will take. It’s all about the quality of the user experience, which is determined by page load time and other key performance indicators. 

As you can see, we started with 300,000 average monthly visits and got to 300 concurrent users. This is another good rule of thumb. You can reduce your average monthly visits by three orders of magnitude and get to a pretty good range for your concurrent users.  Never use your average monthly visit number as your concurrent simultaneous users for your test — it’s way too high. 

Don’t hesitate to contact me directly with your comments and inputs via paola dot moretto at nouvola dot com. You can find me on Twitter at @paolamoretto3 or @nouvolatech.

WEBINAR REPLAY: The Criticality of Performance Testing