Stress Testing with LoadView allows you to determine your web application breaking point or, put it differently, the number of concurrent users at which performance degradation occurs or the app stops responding.
While stress testing determining a load pattern could be a key aspect of the test accuracy. For example, if you put too high load just from the start and the app responds with errors, it doesn’t mean that a lower load can be handled successfully. In stress testing, the load is generated by simulating concurrent user visits on the target site. So, the load pattern when the load is increased gradually with a specified number of concurrent users will be the better choice.
The only problem is to choose a relevant number of concurrent users to simulate during the test. The web analytics tools could be the most preferable way to calculate a realistic starting load. But what should you do when you don’t have analytics data to start with? Here we will discuss the most simple way to set up your stress test scenario using Load Step Curve or Dynamic Adjustable Curve patterns.
Calculating a Starting Load
First, consider the number of your web servers in use and the number of CPU cores available. Generally, according to the industry standards, 25 concurrent users per CPU core could be your starting point, but it is recommended to start with the number 50% lower than a calculated starting point. Increase the load to a value of 5 to 10 times more than the starting depending on what are the performance requirements of your app.
Let’s say your web application is running on a quad-core web server. The number of concurrent users to start with is calculated as follows:
(25 x 4 CPU cores) x 50% = 50 concurrent users
Based on the starting number of concurrent users, raise the load by 25% of the previous step.
Configuring a Load Curve
The second thing to take into account is the transaction run time. Once the Stress Test device has been created and the device validation completed, you can find this value in the Performance Report (View Details > Waterfall Chart).
To make sure transactions were completed at each test step, consider the transaction run time while configuring the load curve. Upon configuring hold each load level twice as long as the transaction run time and then raise it up to the next level. On the picture above we have the transaction run time about 36 sec, so holding a load for 1 min will be enough to finish a transaction even if the response time increases.
You can set up the load curve manually in the case of Dynamic Adjustable Curve until the breaking point in the application performance. Otherwise, set corresponding ramp-up rates for the Load Step Curve.
Find the Load Step Curve for the described example in the picture below.
When the load curve is set up start the test and check the test report for the results.
Determining Breaking Point Using Stress Test Report
Let’s consider a basic HTTP Stress Test with the starting load of 12 users/min. Find the load curve and the test results in the picture below correspondingly.
In the provided example we can see significant growth in the response time and in the number of errors within the period marked yellow on the charts. Depending on your requirements you can consider any point belonging to this period as breaking. For example, if the error rate of more than 0% is considered critical for the application the first time errors appear (e.g., server stop responding for the first time) can be the app breaking point. Or in the case, the response time is a matter – the breaking point is when the response time exceeds a threshold is detected.