Load testing how many users

You can get peak hour page views from your web analytics team or tools such as Google analytics. In this case start with the peak hour page views of 12, to better prepare for the upcoming traffic surge. Another way to determine page views is by reverse engineering checkouts or conversions.

Your site can handle checkouts in an hour and you have a 10 step checkout process. Per Google Analytics support page: A session is a group of interactions that take place on your website within a given time frame. In such a case, you'll need to calculate how many rows of data you'll need over the course of the test. Also, you'll need enough data so that when it's split up amongst the load engines, each load engine has enough data to avoid running out if the load engines are slightly unbalanced.

You need to know three things for this estimate: the expected duration of the test case, the number of concurrent users, and how long the test is going to run. This calculator assumes a steady ramp for the duration of the test: if you need to ramp more quickly and then hold at a level for a longer period of time, calculate the rows of data necessary for the ramp period first, then for the load period.

For details on the calculations, refer to this blog post. Note that this calculator does not take into account dataset rows with a lifetime shorter than "test case" - if you're using multiple data rows per test case iteration, simply multiply the below results by the number of rows in use per test case. Also, if you expect some errors, then pad the dataset to account for those test cases terminating early. When it comes to performance testing, it becomes even more critical that you understand concurrent vs.

Performance testing such as load testing, stress testing, etc. That means concurrent users are the ones who are connected to your website or applications over a time period, regardless of the activities they perform or requests they make.

That means simultaneous users are the ones who are performing the same activity or transactions at a certain point of time on your website or applications.

During that hour, at p. In this case, concurrent users are 15, and simultaneous requests for checkout are 1, The following are some conclusions that we can make from this example:. Simultaneous users are always a subset of concurrent users. That means the number of concurrent users will always be greater than the number of simultaneous users. It will be rare that they would be the same.

Simultaneous users cannot be inactive. They must be active and perform the same transaction at the observation timestamp. Understanding concurrent users and simultaneous users is the key to effective performance testing. If you create your performance tests without knowing the actual difference, you might end up calculating wrong benchmarks and fail the purpose of performance testing.

While doing performance testing for concurrent users, the following are a few things that you should consider while designing your tests:.

This will give you some indication of how moving the virtual-users level affects results, though every possible scenario would need to be tested and this option isn't always viable. Still, considering the architecture of most websites and web apps, testing with fewer concurrent users may produce overly optimistic results.

In other words, false positives are less likely than false negatives. Let's return to our example with 30, requests per minute. If you identify a bottleneck with 5, virtual users at six requests per second, it's unlikely that this is a false positive. Chances are you'll also see a bottleneck when testing 10, virtual users at three requests per second.

On the other hand, if testing with 5, virtual users at six requests per second doesn't identify any bottlenecks, you might have a false negative. Testing with 10, virtual users at three requests per second may reveal that you do have a bottleneck after all.

I often hear of companies that want to run a load test with a million virtual users. Upon further investigation, I discover that their website gets one million unique visitors per day or week, or month so they think they need to run a load test with one million concurrent visitors.

Obviously, this isn't the case. To put this into context, when load testing vendors talk about concurrent users or virtual users, they're usually referring to two aspects:. You should be able to ask your dev or web analytics team how many concurrent visitors you're really getting.

When load testing, it's always best to test with an accurate number of virtual users. However, you can often reduce the number of virtual users and still get accurate results, though you can't know for sure and are taking a risk. Understanding the architecture of your website or web app is critical to making the right call. Good communication with your dev and web analytics teams is a smart place to start.