Stress testing with LoadView allows you to determine your web application breaking point or, to put it differently, the number of concurrent users at which performance degradation occurs or the application stops responding.
Determining a load pattern while stress testing could be a key aspect of test accuracy. For example, if you start with too much load from the start, and the application 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, a load pattern that is increased gradually with a specified number of concurrent users will be the better choice.
Another factor is deciding on the relevant number of concurrent users to simulate during the test. A 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? We will discuss the most straightforward way to set up your stress test scenario using the Load Step Curve.
Calculating a Starting Load
First, consider the number of web servers in use and the number of CPU cores available. According to industry standards, 25 concurrent users per CPU core could be your starting point, but it’s recommended to start with a number 50 percent lower than the calculated starting point.
Starting point = 25 x N CPU cores
Recommended number of users to start with = (25 x N CPU cores) x 50%
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:
Starting point = 25 x 4 CPU cores = 100 concurrent users
Recommended number of users to start with = (25 x 4 CPU cores) x 50% = 50 concurrent users
To specify the number of users to start the test with, use the field of the Start With scenario step.
Configuring a Load Curve
It’s recommended to raise load by 25 percent of the starting point value at each ramp-up step.
To specify the number of users to raise the load per minute, use the corresponding field of the Raise By step.
For the described example, we have the ramp-up rate equal to 25 users/min.
The test duration depends on the maximum load you want to generate. It’s recommended to raise the load to a value of 5-10 times more than the starting point depending on what are the performance requirements of your application:
- If you need to raise the load 5 times, set 20 minutes as the Raise By step duration.
- If you need to raise the load 10 times, set 40 minutes as the Raise By step duration.
In our example, let’s run the test with the duration time of 40 minutes, so the maximum number of virtual users will be about 1,000 users.
When the load curve is set, start the test and check the test report for the results.
Determining Breaking Point Using the Stress Test Report
Let’s consider a basic HTTP stress test with a starting load of 5 users/minute. See the load curve and the corresponding test results in the picture below.
In the above example, we see significant growth in response time and number of errors within the period, shaded in yellow, on the charts. Depending on your requirements, you can consider any point during this period as the “breaking point.” For example, if an error rate of more than 0 percent is considered critical for the application, the first time errors appear (e.g., a server stops responding) can be the application breaking point. Or, in the cases where response time is critical, the breaking point occurs when the response time exceeds a predetermined threshold.