Clicky

Concurrent User Testing

 

LoadView - Concurrent User Testing

Test website performance under the load of an increasing number of simultaneous users. Record actionable data and optimize your systems to scale with your traffic.



Concurrent User Testing From the Cloud

Concurrent user load testing sends simultaneous artificial traffic to a web application in order to stress the infrastructure and record system response times during periods of sustained heavy load.

With LoadView you can increase the number of simultaneous users slowly or quickly throughout your test in order to record how performance is affected under sustained load.

Concurrent user testing is also called simultaneous user testing. The idea behind concurrent user testing is to identify the response time of a website for a specified number of simultaneous users making requests to a website. Concurrent user testing measures how long it takes the server to respond to a specified number of simultaneous requests. A concurrent user test is often used to identify bottlenecks in the performance of a website- basically to find out how many simultaneous users can make requests of a website until the performance of the site is significantly degraded.


Simultaneous User Testing

Send 10 or 10,000+ simultaneous users to your web application to test the performance of your production hardware, software, and infrastructure. You know there are limits to how much traffic your website can handle, but do you know what those limits are? There are a number of layers supporting your website that could be a potential bottleneck including web servers, file servers, routers, firewalls and more. Once you’ve identified the breaking point, you can then strengthen the weak spots in your system.

Use Case Scenario - Concurrent Load Testing

With LoadView, there are a variety of ways you can conduct a concurrent user test. For example, you can begin load testing with as few as 10 simultaneous users, and run these users for 5 minutes to establish your baseline performance metrics. After establishing a baseline, you can increase the number of simultaneous users by 10 users a minute until you reach 100 simultaneous users. You may choose to follow that up with a test run for another 5 minutes for every 100 additional concurrent users to be sure that the results level out.

Some factors that may cause spikes or drops in web page response time while adding concurrent users include additional allocation of memory on the webs server or additional concurrent database connections on the backend. These could easily cause a spike in the average page load speed while waiting for the system resources to become free only to drop back to normal levels once the resources have been allocated.

To test this, you may choose to run a test of 1,000 to 10,000 simultaneous users, or until you feel you have adequately proven that your website is capable of handling peak user numbers. These tests can be used to identify both the volume of users that causes unacceptable page load speeds as well as the number of simultaneous page requests that causes the web app to crash. This may be done by running additional load tests that start at a higher volume of users in order to push the system to its limits.

Concurrent Load Testing from Global Cloud Services

Don’t overload your own network and hardware.
Utilize the globally distributed cloud to generate the traffic you need.

External Concurrent User Testing (From Outside Your Network)

Many website load testing platforms will drive traffic to your site from within your network, but that does not accurately portray real customer traffic coming across the internet. A true load test allows you to take into account additional variables such as Content Distribution Networks (CDNs), load balancers, multi-node server farms and other traffic optimization tools.

LoadView lets you select where your traffic originates from using top tier cloud providers including Google, Amazon and Rackspace. You can allocate different percentages of traffic to originate from each geographic location as you see fit. This allows you to ensure that your website page load speed is consistently fast even under the demand of a high number of concurrent users.

Going Viral with Thousands of Simultaneous Visitors

When your website sees a spike in traffic or an ad campaign goes viral, do you know if your site will be able to handle the increase in simultaneous users? LoadView provides you with the tools to setup a cloud based load test that increases simultaneous users until you have identified the number of concurrent users your website can handle before it goes down. Knowing the capacity of concurrent users on your existing infrastructure is critical to supporting traffic growth and preparing for viral content.


Simple, Powerful Concurrent User Testing

Simply build your load testing script, designate a load curve, and run your test!

LoadView Takes the Hassle out of Testing

Need to test website performance when ten thousand simultaneous users hit our website at the same time? Need to generate millions of hits on your website per test? Worried about managing hundreds or thousands virtual machines in the cloud?

With LoadView, you don’t have to create load testing virtual machine images and upload gigabytes of files to the cloud. Simply setup your load testing script, build a load curve by selecting how many simultaneous users you want to visit the site each minute and you are ready to run your test.


How to Properly Perform Concurrent Load Testing

To properly load test concurrent users, you need a robust tool than can spin up hundreds or thousands of simultaneous users to generate load on your web app. Then the system needs to ramp up the number of simultaneous users until you have proven your site is capable of handling the load or you have identified bottlenecks in your application. A peak load test using thousands of concurrent users from a cloud based system like LoadView can easily scale up to meet the needs of your tests.

Proactively Identify Concurrent User Bottlenecks

When a website is first developed, it is typically not designed to maximize the number of users able to visit the site at the same time. Far too often a concurrent user bottleneck is not identified until it is too late and you are losing site visitors due to a slowdown in site responsiveness or a full blown website crash.

LoadView can initiate a test at a known safe level of traffic and then add additional users every minute so you can see how the website load times are affected as more simultaneous users visit the site. Once you have identified the number of concurrent visitors that pushes response times past your comfort level, you can then begin diagnosing the cause of the slowdown.


Answers to your Peak Performance Questions

Are you looking to identify how many concurrent connections a website can handle before it is significantly slowed down? LoadView will help you identify the answers to your peak performance questions by tracking average page load times under increasing levels of user traffic.

At what point does the Reddit “Hug of Death” or the “Slashdot Effect” take down your website? Find out by performing concurrent user testing with LoadView.



Simultaneous Virtual User Load Testing and Real User Monitoring (RUM)

RUM is a great tool for tracking your website performance in real time from a user’s perspective. Simultaneous user load testing goes a step beyond RUM where you actually generate traffic from simultaneous virtual users in order to stress test a system.

LoadView gathers the metrics from every single individual virtual user session so you can see average page performance at a high level, and then drill down into the details of the performance of each element on the page at any given point in time. RUM provides such insights using code built into the website (usually JavaScript) while LoadView actually records the website performance from the browser level.


Microsoft has set the default value for IIS worker threads per processor to 25 simultaneous users. Thus, a quad core web server should theoretically be able to handle 100 concurrent user connections. This can be used as a starting point to identify roughly how many simultaneous users can make requests to a web server before response times will begin to suffer. This value can also be adjusted up to 100 threads per processor in the IIS settings, but you may hit other limiting bottlenecks by doing this. Such rough performance guidelines also do not consider other factors, such as network equipment like firewalls, routers, packet shapers and other frameworks and components such as databases and file stores that may have an impact on the response time as the number of concurrent users or connections increases.
Because there can be so many factors involved with identifying bottlenecks in concurrent user testing, we typically recommend that you begin the test with a small number of simultaneous users such as 5 or 10 and hold at that level for several minutes to establish a baseline of response time performance. Once you have a stable baseline then you can increase the load on the server slowly to the upper limit of your test. We also recommend holding the number of simultaneous users at a static level at regular intervals so you can generate more solid data on the typical response time for each level of concurrent users.
There is a huge difference between simultaneous user connections and number of visits per hour or page hits per minute. “Simultaneous users” describes actual requests coming in simultaneously generating load within the same period (usually a matter of milliseconds). So, if a website can handle 100 simultaneous users generating 200ms response times, theoretically over the course of a minute, the server could handle 5 requests per user per second, (5*200ms = 1second). Thus, 100 users*5 requests= 500 requests per second = 500 request * 60 seconds/minute = 3000 requests per minute = 3000rpm*60 minutes/hour= 180,000 page requests per hour.

Concurrent User Testing - Push it to the Limit!

Know how many visitors your site can handle. Always be prepared with LoadView.