SYS-CON MEDIA Authors: Mat Mathews, PR.com Newswire, David Smith, Tim Crawford, Kevin Benedict

Related Topics: Cloud Expo, Java, SOA & WOA, Linux, SDN Journal, DevOps Journal

Cloud Expo: Article

How to Choose Where Your Load Should Come From

The goal of a load test is to replicate the traffic & conditions your app experiences in production as realistically as possible

The goal of a load test is to replicate the traffic & conditions your app experiences in production as realistically as possible

As a tester, you understand how important it is to create the most realistic load test possible to provide confidence that your web application won't fail in the field. But how do you know where your load should come from to produce realistic results?

In this article, we have outlined three options most organizations can choose from when determining where your load should come from.

  1. Generate load on dedicated infrastructure in the datacenter
  2. Generate load from a private cloud
  3. Generate load from distributed public cloud locations

There is a time and a place for all three of these options. In this post we will go over when you should do each test and why.

1. Generate load on dedicated infrastructure in the datacenter

When: Perform internal load generation for early stage performance tests and tests on internal IT apps that will be accessed by users behind your firewall.

Why: Load testing from dedicated infrastructure inside your own datacenter is the most common and typically the most accessible way to wring out performance issues in your applications. This type of testing should be performed as part of your regular testing process.

Essentially what happens is you define specific load and performance tests that push on the individual modules and user paths within the system, and make sure that no unintended bottlenecks were introduced during development. The kinds of issues you'll work out with this localized, constrained testing include:

  • Inadequate transaction design
  • Broken links
  • Poor configuration
  • Memory leaks
  • Unoptimized code
  • Sub-optimal session model
  • Ineffective caching
  • Database indexing, connection, and concurrency issues

While performing this type of load test on dedicated equipment is easy, there are a few issues with using this approach as your sole means of load testing - the first of which is that many companies simply do not have adequate dedicated infrastructure resources to realistically test application performance at scale. The capital expense involved with acquiring and managing network equipment, servers, and applications for the sole purpose of performance testing can be hard to justify - especially when you consider that this infrastructure may sit idle for a significant portion of its life.

Second, load testing from anywhere inside your own datacenter environment will test only application performance. It will not test the full capabilities of the datacenter (including network configurations, load balancing, or security systems) and therefore will not produce a realistic picture of the user experience.

Running load tests from your internal environment is an important part of improving application performance, but it is not sufficient. You should integrate tests like those outlined above as a frequent part of your build & integration process. As you near the end of a release cycle, you'll have confidence that the application's functionality performs well under periods of high traffic.

2. Generate load from within a private cloud

When: Perform tests from a private cloud when you need to ramp up your load generation infrastructure quickly for larger tests.

Why: To address some of the issues above, many organizations are running load tests from within their private clouds. Operating on this type of infrastructure has several benefits when compared with the first approach that has been outlined.

Functionally, this method of testing is best suited to the same types of performance tests that you would execute using dedicated hardware: database optimization, transaction design, and the rest. However, private clouds address some of the problems with running on dedicated hardware.

First, a private cloud can be significantly less expensive to operate, specifically because the cloud infrastructure can be leveraged across many different applications. When you are done with your load test, virtual machines can be reassigned to complete other tasks such as analytics, development, or other cloud-friendly business processes. This allows an IT organization to distribute infrastructure costs, thus lowering the overall expense.

Second, this approach lends itself very easily to more realistic scaling. You can grab more cycles and more disk space as needed, ultimately driving a more aggressive stress test of the application.

Chances are, however, since you are testing from within your own network and environment, you are still not stressing the complete datacenter. As a result, this type of load generation approach won't necessarily give you an accurate picture of what your users will experience in periods of high traffic.

3. Generate load from distributed public cloud locations

When: Perform this test for when your app will be accessed primarily from users outside your firewall from distributed locations.

Why: By running your load tests from outside the datacenter in a public cloud or even a remote private cloud environment, you will get a good picture of how your datacenter infrastructure handles high traffic. This third type of load will test a part of the application's delivery that no amount of testing from your own datacenter can duplicate. This includes:

  • Load balancers
  • Networking equipment configuration
  • Data center connectivity and bandwidth
  • Web firewalls and security systems
  • In-network caching and content distribution
  • Network architecture
  • DNS, web latency, network congestion

It's important to focus your testing so it puts the load in the right place. For example, load testing firewall or load-balancing infrastructure. You may even choose to load test multiple applications that exist within the same data center at the same time to see if it chokes up for any reason when the load is applied.

Another major point that many testers don't often consider is the fact users are accessing your app from many different regions across different service providers. To get a realistic picture of the actual user experience, it is important to see what their experience looks like from their access points anywhere in the world. This will give you a better understanding of what happens to your web application when users from different parts of the world are flooding your website with traffic.

Prevent a Disaster, Don't Cause One
The ultimate goal of a load test is to replicate the traffic and conditions your app experiences in production as realistically as possible to give you confidence that your site will not fail at peak times with actual live users. By looking at the three major options of where your load should come from, it will give you a better idea of how your app will perform under stress.

No matter what, each of these tests will catch something different in your application. And we all should know by now, if you catch a bug earlier in the process you won't have to pull out the big bucks to fix a major disaster down the road. Prevent a disaster, don't cause one.

More Stories By Tim Hinds

Tim Hinds is the Product Marketing Manager for NeoLoad at Neotys. He has a background in Agile software development, Scrum, Kanban, Continuous Integration, Continuous Delivery, and Continuous Testing practices.

Previously, Tim was Product Marketing Manager at AccuRev, a company acquired by Micro Focus, where he worked with software configuration management, issue tracking, Agile project management, continuous integration, workflow automation, and distributed version control systems.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.