An Introduction to Load Testing
Huge traffic spikes can occur when you launch a new product or feature, run a successful marketing campaign, or get featured on a popular blog or news site. Sometimes, traffic spikes happen without warning.
If your site handles the traffic and delivers a great experience to everyone, the traffic spike will be a big win. On the other hand, if your site fails to perform well, it could be an embarrassing and costly failure.
High traffic events raise the stakes for your business. Lots of upside, but also a big potential downside if you fail to scale.
Reducing Risk from High Traffic Events
Can we reduce the downside risk of a high traffic event, while maintaining or increasing the upside?
Load testing is a way to do exactly that.
By testing heavy traffic ahead of time, you can find out how your site will respond when the flood of real users hits. Better yet, you can use your realistic simulation to optimize and improve your site, so it handles real traffic flawlessly.
Load and stress testing can help you answer questions like these…
- Will my site perform well on our busiest day of the year?
- Do I have enough cloud infrastructure or hardware to run this application at scale?
- Is autoscaling working properly?
- Does my app deliver fast response times and a good user experience even under peak load?
- When pushed to the breaking point, does my application recover gracefully, or crash hard and lose data?
- Are there concurrency issues or “heisenbugs” in my application that only appear under heavy load?
- Do I have memory leaks or resource exhaustion that appears after extended usage?
- Are our redundancy and failover systems in place and working properly?
Answering these questions with concrete data is critical, if you want to deliver a fast and bulletproof user experience to your customers during high traffic events.
Unlike functional testing, which can be accomplished by a single person, load testing requires special tools to simulate hundreds or thousands of concurrent users interacting with your site in a realistic way. Loadster is one of those tools.
Loadster is designed to load test websites, web applications, and APIs. For the sake of brevity, in this manual we will often refer to them generally as “sites”.
Answering the Important Questions
If you’re responsible for an important site or web application, you already know how important it is to deliver a fast and stable experience to your users.
To plan a successful load test, you’ll need to compile specific requirements stating how many concurrent users the site needs to serve, what range of end user response times or page load times is acceptable, and what kind of user behavior is to be simulated. If you’re working with stakeholders, the process of gathering these requirements might not sound fun, but it’s actually a great opportunity to synchronize everyone’s expectations around the testing effort and about how your site is expected to perform in real-life traffic floods.
That said, load testing techniques can be useful even if you don’t yet have specific performance or scalability requirements. In the early stages of a project, it can be incredibly useful to run some exploratory load tests to see what bottlenecks you encounter. Running identical load tests in rapid succession, while making changes to your site and environment, is a great way to find obvious and not-so-obvious performance problems.
Tuning an existing website, web application, or API is one of the quickest ways to improve its value. But don’t operate in the dark! When you’re tuning for performance and scalability, you’ll first want to create a repeatable load test to simulate the same user behavior with the same amount of load each time, so you can accurately compare performance before and after each tuning change. Avoid the pitfall of changing parameters haphazardly, without a steady repeatable load test to verify each change.
Performance Regression Testing
If you’re constantly releasing changes to your web application, you’ll want to know if each revision makes performance better or worse. Running the same load test against each build lets you compare high-level performance metrics to see if performance has improved or degraded. It doesn’t need to be a manual process, either: add Loadster to your continuous integration pipeline to get automatic performance test results from each build.
If your site receives a temporary spike in traffic, does it handle the spike gracefully and recover quickly afterwards? Or does it break down and remain sluggish? It’s fairly common for web applications to suffer bad performance for a while after a large spike in traffic,sometimes requiring a restart. This can happen when an internal resource is exhausted, when old requests are queued up causing backpressure, or when your autoscaling configuration starts to snowball. Since the aftermath of a traffic spike is so unpredictable between applications, load testing is a smart way to find out if there’s a problem.
All systems have a breaking point. When you’re building and maintaining a complex system such as a web application or API, it’s important to know exactly what happens when it’s put under excessive stress by heavy traffic. Do database operations intermittently fail, leaving the system or its data in a half-baked or unclean state? And once the flood of traffic subsides, does the system recover gracefully on its own, or does it remain broken and require manual intervention? Pushing your site beyond the limit with a stress test will answer these questions.
Web applications sometimes run smoothly for a while and then bog down as some resource is gradually exhausted. It’s not great when this happens in production. An extended load test, even at moderate load, will measure the application’s performance and stability over a 24-72 hour period. If you see gradual degradation under sustained load, there’s a good chance that some resource is being exhausted. It might be a hard limit like physical memory, or a soft limit like an internal cache or leaking database connections. Either way, you’ll be glad you found it ahead of time.
Progressively De-Risking Your Site
You might be thinking “Wow, that’s an overwhelming list of things to test”. And it’s true, if you actually load tested all the things all the time, that would take a lot of effort.
But the good news is, reducing the risk of crashing from high traffic events isn’t an all-or-nothing endeavor. You can de-risk your site substantially, even with just a little bit of testing.
Load testing, like so many things, follows the Pareto Principle: something like 80% of the outputs come from 20% of the inputs. So by running successful load tests on the parts of your site that matter, you can substantially reduce the risk of costly failures.