Stress testing means simulating a heavy load on the server to find the maximum number of users the server can handle. This number is also called a crash point.
The crash point does not necessarily mean that the server crashes or hangs. It can mean that errors start happening or that the server performance or response time is below the level that your service-level agreement (SLA) defines.
Test parameters
To create a stress test, use the Ramp Up load profile with a large number of users.
In addition, you need to create assertions and server monitors to check the server response against the limits specified in your SLA. When the responses take longer than the SLA specifies, your server runs out of the processing power, or errors start happening – you have reached the maximum capacity of your server.
If you use the Ramp Up profile with the VUs load type, you can see that the number of concurrent virtual users at the crash point was reached easily: check the VUs metric in the Global Metrics graph and notice the point, when the response time exceeded the SLA, or errors occurred:
Click the image to enlarge it.
To reach the crash point faster, you can use the Ramp Up profile with the Rate load type, and configure the test settings so that new virtual users arrive to the server before the existing users finish their work.
You can quickly create a stress load test by using the Stress load test template. By default, it will create a test with the following parameters:
| Parameter | Value |
|---|---|
| Duration | 120 minutes |
| Load type | Rate |
| Simulated load | Ramp Up, from 0 to maximum number of arriving users per second supported by license |
| Think time | 1 second (10 ms for trial users) |
| Warmup time | 0 seconds |
| Assertions |
Time taken – Average; Running VU; Assertion failures – Per Second; |
As an option, you can configure server monitors.
ReadyAPI will create a statistics chart for the load test. You can create it manually as described below.
To see how many virtual users ReadyAPI was simulating when the crash point was reached, switch to the Statistics page and create a graph for the Failures – Total and Running – Value metrics in the Test Case category. They represent the total number of errors and the number of simultaneous virtual users:
Click the image to enlarge it.
 |
The Statistics page is only available for a ReadyAPI Performance license. To try how it works, use a trial ReadyAPI Performance license. You can get it for free on our web site or activate it from the product. |
Assertions and server metrics
To estimate the server performance, you can track various server-side metrics or use assertions.
Server Metrics
With ReadyAPI, you can track various server-side metrics like memory and CPU usage, the number of database requests per second, and so on. To do this, you need to configure server monitors in your load tests. For detailed information, see the topics of the Server Monitoring section.
You can check metric data on the Server Monitoring and Statistics pages of the load test inspector.
The exact metrics to be checked depend on your server type and on the type of your server applications. For information on the available metrics, see Monitor Reference.
Assertions
Below are some load test assertions that you may find useful for creating stress tests:
| Assertions | Description |
|---|---|
| Test Target – Discarded – Total | Lets you control the number of requests that the server declined. |
| Load Test – Failures – Total | Lets you check the total number of errors that occur during the test run. |
| Test Target – Failures – Total | |
| Test Steps – <Test Step Name> – Failed | |
| Test Target – Time Taken | Lets you control the request simulation time for the target Test Case and individual test steps. |
| Test Steps – <Test Step Name> – Time Taken |
Tips
-
Creating stress tests usually requires more virtual users than it is available for the Base license. So, you need a ReadyAPI Performance license. You can request a free trial on our web site, or from within the product.
-
Stress tests often require more users than a single computer can generate. You can use ReadyAPI Performance distributed and cloud tests to generate the load from multiple locations.
-
If you have some estimation of the maximum concurrent visitors for your web site, use it as a base number for the ramp.
If you use the Ramp Up profile with the VUs load type, and if the test passes successfully, this means that the crash point is over the peak value. Increase the base and peak values twice and repeat the test.
If you have the crash point immediately at the base number of users, then this could mean that the crash point is somewhere below that base value. Decrease the base value twice and run the test again.
-
If you use the Ramp Up profile with the Rate load type, pay attention to the execution time of the test case to be simulated.
Let's suppose that this test case runs for 20 seconds. To simulate the load increase, you need to set the test so that it starts virtual users each second, rather than minutes or hours. This way virtual users will “come” to the site faster than the existing users will leave it.
For the first 20 seconds, the number of virtual users on the server will grow exponentially. If you start one more virtual user each second, then, in 10 seconds, the test will be simulating 55 virtual users.
In 20 seconds, initial virtual users will start finishing their work and the load will grow more linearly. If server responses slow down, the number of simulated users will increase very fast. This happens, because it takes virtual users more time to finish their work, and more users will be working with the server each second.
Click the image to enlarge it.
See Also
Fixed Profile
2. Load Test Editor Interface Overview
ReadyAPI Performance Licenses