How much traffic can your application really handle? At what point does it stop responding? What does an impending overload failure look like?
If you can’t answer these questions, you’ll need to do a stress test.
Stress testing is often an afterthought. Some regard it as too expensive. But it likely will be performed in your live production environment even if you don’t intend to do so. Load-related breakdowns happen. Then, after digging through the digital wreckage, you will have learned the limits of your application and environment.
Much better to perform the stress test deliberately, away from live traffic, and in advance of any natural occurrence in the wild. Testing helps prepare for eventual load failures in production, uncovering the error codes and peculiar behaviors seen as the limit is approached. It allows developers to tune for maximum performance. It also feeds information to planners and business contacts to help accommodate future growth.
You’ll need a capable testing tool. Hewlett Packard Enterprise LoadRunner has long been the gold standard in test suites. It’s been joined by competitors like WebLOAD, L Appvance, NeoLoad, and the open-source JMeter. LoadView is another option in terms of a comprehensive tool. In response to competition, HPE now offers a “community edition” of LoadRunner free for up to 50 v-users.
In the most complex and demanding environments, you’ll likely need more than one tool. It seems some critical information in one component or another of a complex app remains invisible to any single testing product. Website load testing is a complex process, and a this is why it might require the use of a variety of tools.
The stress test requires considerable planning. A common strategy is to simulate a sudden burst of interest in an online application. Usually, these real-life events start with a trickle that gradually becomes a flood. The test should follow a curve to allow all parts of the application to stabilize as usage increases. Baselines are established for comparison. Only then are the taps opened full. The full-throttle scenario should be sustained long enough to find a breaking point, or to gain confidence the application has more than enough headroom to handle any likely usage pattern.
While the test is underway, staff should track system logs and performance meters as well as application and database logs. A sysadmin or engineer must monitor system utilization during the test. This information will be critical to diagnosing impacts to the application from server problems, and in creating a system capacity plan.
Stress testing–though often difficult and time-consuming–is essential. It’s a little now or a lot later.