In Part 1 I described how the cloud is revolutionizing load testing and the advantages it provides to ensure that your web applications perform well in production. We also looked at what capabilities you should seek out when selecting a load testing solution.

In Part 2, I will offer the limitations of a test strategy that relies solely on cloud-based testing, highlighting the need for a complementary internal load testing solution. I will also discuss several best practices for load testing in the cloud. Understanding how to apply the right tools and practices to make the most of the cloud is fundamental to cloud-based testing and vital to ultimately going live with total peace of mind.

The advantages to load testing with the cloud are clear, but internal testing still has its place in the overall test plan, particularly when testing from outside the firewall is not feasible. Internal testing also helps you to isolate effects that are due to your own application or infrastructure from those that are outside your firewall and potentially beyond your control.

The advantages to load testing with the cloud are clear, but internal testing still has its place in the overall test plan, particularly when testing from outside the firewall is not feasible. Internal testing also helps you to isolate effects that are due to your own application or infrastructure from those that are outside your firewall and potentially beyond your control.

Isolating Root Cause
When load testing uncovers a problem, the next step is identifying which layer in the delivery chain is causing the problem. You can use monitors to check performance metrics such has hits, average response time per request, and average bandwidth for each layer or piece of equipment in the chain. You can also employ application performance management (APM) solutions to identify bottlenecks in the code. These techniques work reasonably well when there is a single source for the performance slow-down.

When there are multiple problems, both inside and outside the firewall, it can be difficult to sort out the root causes because the symptoms are often commingled, making them difficult to isolate and resolve individually. For this reason it's important to have a cloud load testing solution that you can also apply within the firewall. You can then separate the problems that exist within the firewall from those caused by layers outside it. The ability to test a subset of the delivery chain in this way makes it much easier to find the root causes of performance problems.

Reproducing Tests
Often, you need to precisely measure the effect of changes made to the application code or settings. For example, you may need to determine the performance improvement that results from resolving a specific defect or evaluate performance for a range of cache sizes and other settings.

With cloud load testing, such precise measurements are difficult because of variations in Internet traffic and bandwidth availability at the data center level. Such variations can make it almost impossible to duplicate conditions from day to day or even within the same day.

As with isolating root causes, this situation also highlights the need for internal testing, in which you can better manage the conditions of the test, stabilize the testing environment, and take precise measurements to get more reliable performance metrics for comparison.

Conducting Small Scale Tests
Not all load testing requires hundreds of load generators. Even applications that anticipate many thousands of concurrent users are initially tested with a small population. These smaller scale tests require only a few machines may be easier and less expensive to conduct internally if the machines have already been purchased and are available for use. These tests can be carried out within the firewall to conduct tests that don't require a heavy load or the full delivery chain. To keep cloud expenses down, use available real machines when they can provide the information you need, and employ load testing with the cloud when necessary for larger scale, more realistic tests.

Testing Inside the Firewall
Of course, some testing use cases preclude the use of the cloud. If you're developing an enterprise web application that was not designed to be accessed from the Internet, then it's not a good idea to expose it outside the firewall solely for the purpose of load testing with the cloud. Likewise, if your pre-production environment is not set up to be accessed from the Internet, you'll want to have an internal testing solution that can be used within the firewall. Ideally, you want to use the same load testing solution for both internal testing and testing with the cloud, so that the scripts you developed for internal pre-production testing can be reused in production cloud-based testing. Using different tools for internal and cloud testing would not only require a rewrite of the scripts, it would also increase licensing and training costs.

Best Practices
The following best practices can help you maximize the advantages - and minimize the challenges - of load testing with the cloud.

Employ a Two-Stage Process
A two-stage process for load testing enables engineers to employ internal and cloud testing in the situations for which they are most effective and appropriate. In the first stage of the process you conduct internal tests with a medium load to quickly identify and resolve preliminary performance issues. Then increase the load incrementally with one or more load generators in the test lab. After the performance has been validated internally, proceed to the second stage, cloud-based load testing, for large scale tests that validate the entire delivery chain of the application.

This hybrid approach addresses the key challenges facing organizations that attempt to rely on testing from the cloud only:

• It enables teams to isolate problems. The source of any performance issue identified in the first stage is clearly within the firewall (because no other systems are involved in the test). It's easier to pinpoint and fix internal problems when they are not being compounded by other issues that originate outside the firewall.
• It enables earlier testing. With the two-stage process, you don't have to wait for the application to be deployed and accessible from the Internet to test it. You can test internally earlier in the application lifecycle when defects are easier and less expensive to fix.
• It enables reproducible tests. With internal testing you have much more control over the environment, so you can precisely measure the effect of code or configuration changes on application performance.
• It provides a better understanding of each major area of the delivery chain. You can compare the results of the same test scenario run internally and from the cloud to get a clearer picture of how the application server and network infrastructure contribute to overall response times.
• It lowers costs. Cloud testing is based on a pay-per-use model. When you can test internally on hardware you already have, you can reduce the amount of testing that you need to perform from the cloud and cut costs.

Use Different Cloud Providers
There are several advantages to using multiple cloud providers. First, it helps you test from more geographical regions, which provides more realistic results that capture the effects of various third-party servers and content delivery networks. Second, it's more scalable. For exceptionally large scale tests, you can engage multiple providers simultaneously to bypass limitations that a single provider may place on bandwidth or the number of machines in use. Third, it enables you to detect potential network issues at the cloud provider level. If test results from virtually all providers show acceptable performance, but you're seeing significantly worse performance from machines on a particular provider, then you can safely conclude that there is a temporary problem with only that provider, not your application. Load testing solutions that are locked into a single provider limit the test engineer's ability to conduct realistic, reliable, large-scale tests.

Secure Your Data
In internal pre-production testing, the data used is often fake - not actual customer or user information. Further, you can be reasonably assured that any real data used is safe because testing is being conducted within the firewall. This is not the case when testing from the cloud on production data. You'll need to take steps to ensure that any accounts, scenarios, detailed error messages, and other sensitive data involved in your tests are secured.

Encrypt the communication between your controller and load generators. This helps secure data sent to the load generators during the test (including account information) as well as the data that is retrieved (including error messages). If possible, use SSL to secure the communication between the browser and the tested server. Last, ensure your load generators are secured with their own firewalls to protect them from outside threats.

Tune Load Generators
To ensure that your load generator machines in the cloud are capable of generating large loads, you must properly tune the system to support the creation of a high number of sockets and threads per process. In addition, allocate an appropriate heap size for Java-based load generators. The default settings for a typical machine allow all programs to share its resources fairly. In the case of load generators, the machine is dedicated to a single task, so you can improve performance by allocating a significantly larger share of the available resources to the load generation tasks.

Monitor Your Servers
Once you've identified a performance bottleneck, you need information to track down its root cause. This information should be gathered during the test by monitoring each component of the infrastructure including application servers and database servers. Specifically, you want to monitor both the system - including the operating system, disks, and network - and the server software - including connection pools, threads, cache hits, and indexes.

Linking all the information gathered during the tests with the tests themselves is much easier when the monitoring is integrated with your load testing tool. This enables you to correlate the response times and errors generated by load testing with the monitored data to track down the cause of problems quickly. A cloud testing solution that has no ability to monitor activity inside the firewall cannot integrate and correlate the tests it initiates from the outside with what is happening on the inside. With such a setup, test engineers will not have all the information they need to quickly identify the sources of performance problems.

Summing It Up
Even with all its potential benefits, cloud testing cannot meet all the challenges facing performance test engineers. In practice, cloud testing is most effective when combined with internal load testing in a two-stage process that makes use of multiple cloud providers and both internal and external infrastructure. You can be optimistic about using the cloud, but don't get caught up in all the hype. The key is to think of cloud testing as the delivery mechanism that is just one (albeit an important one) part of an overall load and performance test strategy.

• Benefits of Load Testing in the Cloud (Part 1)