For anyone who’s played around with the programming language, Perl, you’re probably familiar with the motto, "There’s more than one way to do it.”
That’s not just true for Perl, though!
Depending on how you configure your load tests, you’ll see that your website/application and infrastructure react differently. That means running a diverse range of tests produces multiple outcomes, and more data is almost always a good thing.
Here are four types of load test configurations that will teach you different things about your web properties and give you the insight needed to optimize their performance.
Load test
Ah, ol’ reliable. When you want to understand if you’re meeting your performance goals, this is the type of test you’ll run.
You likely already have a basic understanding of how much traffic you’re typically getting, so you’re running load tests to make sure you’re continuously meeting performance standards as you build new features for your product.
Let’s say you’re seeing around 1,000 concurrent users during your hours of operation. A configuration similar to the one illustrated below is a good way to see how your app and infrastructure will stand up to that.
You should have some performance goals in mind, and one of Load Impact users’ favorite features can help you make sure your website or application is living up to those standards — Performance Thresholds.
Simply set thresholds for VU load time, page load time, failure rate or any of your custom metrics, and you’ll see a Pass/Fail metric for each test, so you’ll know immediately when something’s not up to snuff.
If this is your first time running load tests, remember that your application and infrastructure might not be as rock solid as you think. We've had thousands of users run load tests that quickly crashed their applications (or staging environments).
But that's OK! It just means that your load test has morphed into a stress test, which is the next type of test configuration we're covering.
Stress test
This is another common test for our more than 200,000 users.
Stress tests answer the question: How many users can your application handle, and when will it break?
In this configuration, you’re going to write the test to include more concurrent users than your application typically sees, and even more than you think it will be able to handle.
It’s important to note that a stress test doesn’t mean you’re going to jump right into a ton of concurrent users — that’s a different type of test we’re going to cover in a minute.
A stress test can be only a couple steps, or it can be many, as you see in the example below. No matter how many steps you include, just remember this type of test is about finding out what happens when pushing the performance limits of your app — so don’t worry about being too aggressive.
You may have heard this kind of test also referred to as a "step up test.” The terms are essentially interchangeable, so keep that in mind if you’re hanging out with a group of friends and talking some serious load testing business.
Spike test
The spike test is defined by its short time at a normal level then a quick ramp-up time to the "spiked” level. Notice how quickly the example below jumps from 1,000 to 10,000 concurrent users.
A popular example here is if you’ve bought advertising on a big television event, such as the Super Bowl or a popular singing competition.
You’re expecting people to see your product or website and immediately go there, which can end with disastrous results if you haven’t tested for this scenario and made performance optimizations in advance.
Soak test
If you’re expecting a long average session duration from your users or you want to simulate days worth of traffic in only a few hours, then the soak test is a must in your performance testing lifecycle.
The soak test uncovers performance issues stemming from a system being under pressure for an extended period of time.
You can find long-term problems conducting soak tests, such as memory leaks, resource leaks or corruption and degradation that occurs over time.
The industry standard here is to run configure the concurrent users for these tests at about 80 percent of your max capacity.
