Assuming you haven’t spent the last couple of years living under a rock, you’re bound to have been bombarded with all sorts of propaganda about “The Cloud”. “The Cloud”, according to the marketing types, is the greatest thing since the invention of bread, surely able to solve all of our needs, whether technology-related or not. While the hype for the cloud might be frequently and frustratingly overstated and confusingly applied in odd places (can someone please explain to me the Microsoft Cloud commercial where the woman goes “to the cloud!!” so she can generate a family photo? What does this have to do with the cloud? Isn’t this just Photoshop?), I’d like to discuss one place where the cloud adds a great deal of value: Load and Performance testing.
In this post, I’m going to talk about the benefits of using the cloud as part of your load and performance testing practices, as well as point out some common approaches in choosing a cloud solution.
In a future article, I’ll discuss some of the challenges the cloud presents and some best practices to deal with these challenges.
For those of you that have ever heard me present on load testing, you are well aware of how fixated I am on the need for load testing that truly emulates the real world behavior of your end users. And for those that haven’t, understand that, in my opinion, if you are not doing accurate and realistic load testing, you might as well stop now. Inaccurate load testing, in my view, is often worse than doing no testing at all. I’ve seen far too many organizations perform inaccurate testing, that is testing that falls short of mirroring what their end users are really doing, and use results of this testing to lull themselves into a false sense of security. Then they go live with their web application, which in turn experiences end user behavior which wasn’t fully tested for, and are surprised when their web application falls down.
In my mind, The Cloud immediately brings two distinct advantages to our load and performance procedures that help us better model this realistic behavior. The first is what I call “Instant Infrastructure”.
In today’s economy, customer-facing web applications are experiencing vastly increased user loads. These loads might increase consistently over time due the success of your business, or they might be more sporadic in nature, perhaps due to a seasonal sales or new advertising campaign. And as we know, if your application is unable to handle this increased load – whether the application experiences poor performance or downtime (or both) – you run the risk of losing business or experiencing damage to your brand.
In order to avoid these potential problems, performance testing should include load tests with very large user loads. And unfortunately, trying to maintain a test environment that generates this kind of load can be both costly and challenging. Creating an environment of this size can typically require tens or even hundreds of machines. Purchasing and configuring these systems requires a significant investment of time and money. And after the machines have been acquired, configured and used for the immediate load testing need, they may end up siting unused for long stretches until they are needed for the next large scale load testing project. Not a very cost effective approach in a lot of situations.
Here’s where the “Instant Infrastructure” comes in. By accessing a test infrastructure in the cloud, you can rapidly access as many load generating machines as you need, on demand. With this approach there is no need to spend weeks setting up and configuring dozens of real machines. The cloud testing provider will automate this process as well as keep all the machines updated. This obviously saves you from the substantial up-front costs of purchasing and maintaining the load generating machines. Most cloud testing providers also use a pay-as-you-go model, for which you rapidly access the testing infrastructure you need, when you need it, and only for as long as you need it. From a business standpoint, the cloud lowers total cost of ownership, while increasing flexibility.
The second key way The Cloud helps us achieve more realistic load tests is its ability to allow testing from disparate locations. In many cases your real world users are not sitting inside your firewall, they are instead probably accessing your location from their office, their home – locations around the country or around the globe. As such, for performance testing to be accurate it must include load generated from these locations as well. If your testing only uses load generating machines inside your firewall, you’re not testing the entire delivery chain. With the cloud, you can execute load tests that access your web application just as your users will—from outside of your firewall—and validate all components of the delivery chain, including the firewall, DNS, network equipment, and ISP. These tests are not only more realistic, but they also allow you to understand the impact of third-party components, such as content delivery networks, analytics servers, and ad servers. And you know how I feel about realistic tests.
Now that I’ve discussed the advantages that the cloud can bring to your load testing, I’d like to talk a bit about some of the limitations that relying SOLELY on a cloud solution might present. Like any other part of our testing effort, understanding the tools we have at our disposal and how to use them is the key to being successfully. Just because we have some great tools in our toolbox doesn’t necessarily mean they will help us everywhere, especially if they aren’t used correctly. The cloud is no exception.
First of all, load testing from the cloud should not replace internal testing; that is, testing with load generated from within the firewall. Too often, I’ve seen organizations complete their load testing scripting and then move right away to running large scale tests with the cloud. To me, this approach misses a key step. Load testing cycles should include a combination of tests run from both inside and outside the firewall. You may be wondering if I’m contradicting myself – based on my earlier cloud discussions, the cloud seems like the way to go with all of our load testing, doesn’t it? Why would I want to do anything else? There are a couple of reasons why “inside the firewall” testing should still be considered.
First, as we’ve already seen, driving the test load from cloud load generators allows us to test the whole delivery chain. And so our performance measures will include not only the performance of the application but of also all the networking pieces that exist between the application and the end user. Running a load test from INSIDE the firewall will provide us with performance counters of really just the application itself. So combining the results of these two tests can yield some very powerful analysis. If we correlate the same measures gathered from “inside the firewall” tests with those gathered from tests run from the cloud, we can get a much better sense of the impact the delivery chain itself has on the measured performance. Without these combined tests, it can be very difficult, if not impossible, to understand the true root cause of performance issues – whether they are impacted by things under our control (inside the firewall) or those we may not have control over (outside the firewall).
As you can see, the cloud is opening new opportunities to improve the scale and realism of load testing as well as saving time and lowering costs. But, in order to realize these benefits of the cloud, a proper approach is required. Part of this approach is the actual selection of a cloud load testing solution. When selecting a cloud testing solution , keep in mind that it’s not just about moving to the cloud itself but also making sure you choose the right solution. In my next post, I will discuss some ideas of how to best approach the selection of a cloud testing solution.