The purpose of web server stress testing is to find the target application’s crash point.
The crash point is not always an error message or access violation. It can be a perceptible slowdown in the request processing.
Stress testing can give answers to the following typical questions:
What load can crash the server application?
What parameters do we monitor to make sure that the server remains available?
How do I fail over my web servers and databases?
Record one or more user scenarios.
(Optional) Modify the recorded traffic.
Create a load test that will simulate several virtual users.
Assigns scenarios to the users (you can assign the same scenario to several users or assign an individual scenario to each user).
Configure the created test:
Specify the browser, connection speed and start delay for each user.
Specify the workstation for each user.
(Optional). Specify Quality of Service settings to estimate the performance of the tested web application.
Run the test.
Analyze the load test results and check whether the application “crashes”.
If the test results contain warnings and errors, this may mean that you have found the crash point.
Once again, a crash is not always an error, this may be unacceptable performance.
If the application did not crash, increase the number of virtual users and perform the test again.
During the test run, you can monitor the server parameters on the Runtime > Graphs page in real time. The parameters of primary interest in stress tests are as follows:
Response transfer speed
When the server crashes, you may find this out by response transfer speed decrease, or the number of passed requests. In addition, the server may report errors.
As you can see in the image above, the simulation fails when trying to simulate 300 virtual users.
Let's suppose that your application works fine with 10 virtual users, but crashes when working with 300 virtual users. This means that the application crashes at a point between 10 virtual users and 300 virtual users. To get closer to that point, split the user interval into two parts: 10…145 and 145…300, and run the test with 145 virtual users.
If the test with 145 virtual users was not successful, you can then cut the first interval in half and run the test using 77 or 78 virtual users.
If the test with 145 users passes, cut the second interval in half and run the test using 222 or 223 virtual users.
Continue splitting the interval until you find the crash point.
Here, we can see that the crash point for the given application occurs at simulation of 220 virtual users.
Reviewing detailed results for the crash point run may clue you up on the server’s instability.