Stress-Testing Your Website with CloudBees Accelerator

Last month, I had the honor of being chosen to present a session at DevOps Enterprise Summit (DOES 14) on the subject of test acceleration with CloudBees Accelerator. When I was preparing the content, it struck me that I could do much more than just test acceleration, and so I renamed the presentation to "How to Accelerate Anything* with CloudBees Accelerator. " It was great fun and I very much enjoyed speaking about the subject. During the presentation I brought up the option of using CloudBees Accelerator as a way to stress-test web sites. The most obvious example I found for this was the famous crash of the HealthCare.Gov , which caused so much consternation for the Obama Administration. The problems were eventually solved and several million Americans have since signed up for health insurance through the site, but it's pretty obvious the contractor designing it would have saved everyone a lot of trouble had they stress tested the site prior to going live. Think about it -- how often do we design web sites knowing that on day one, the moment you go live, hundreds of thousands of users will go "Click!" and turn it into a smoking hole in cyberspace? Once I finished my presentation, one of the attendees asked me if I had examples of stress testing of a web site. I said I didn't, but like a good Marine, I also said that I would find one. And sure enough, I did. It's a simple one that does not address all load testing possibilities and requirements, but it succinctly demonstrates the technique.

Step-by-Step Example:

Acme Laboratories (www.acme.com ) describes themselves as "Purveyors of fine freeware since 1972. On the net since 1991." One of their products is called http_load (www.acme.com/software/http_load ) and comes with full source code. The product is described thus: "http_load runs multiple http fetches in parallel, to test the throughput of a web server. However unlike most such test clients, it runs in a single process, so it doesn't bog down the client machine. It can be configured to do https fetches as well." You give it a file containing a list of URLs that may be fetched, a flag specifying how to start connections (either by rate or by number of simulated users), and a flag specifying when to quit (either after a given number of fetches or a given elapsed time). There are also optional flags for checksums, throttling, random jitter, and progress reports." To test it, I decided to run it against a couple of website home pages. To configure the test, all you need is a text file with the URL's you want to pound on during a test. For example, I put these two lines into a file named url.file:

You could do much more complex things with this, such as using a simple PERL program to generate randomized configuration files every time you instantiate each test. To run it, I chose a simple test configuration (http_load can do much more than this, but I have great respect for "K.I.S.S."). After downloading the software and performing an "emake install" to compile and install the binary and main page, I ran it like this:

It in turn gave me this little report:

Now, let's move on to the acceleration.

It's great that we can do this with one call off a list of URL's, but what if we really want to attach a vise grip to a web site? To do that, you would need an army of machines, right? Or better yet, how about spinning up an army of virtual machines on your favorite cloud server provider, and configure them so they come up already set up with Accelerator agents that automatically register themselves with your cluster manager, ready to do their worst? In my case, I have four agents on a VM on my laptop, so I wrote a tiny Makefile to have emake line up the tests and fire them off, one per agent:

Because each test is set to run 5 http fetches per second over 10 seconds, the test takes 40 seconds to complete in serial mode. However, if you launch this with CloudBees Accelerator's emake in clustered mode, it should only take around 10 seconds for all tests to run, plus a little overhead for the work of lining up the missiles and getting them in the air. Scale this up to your VM farm, and you have yourself a very effective, efficient and easily scalable load testing platform . Mission accomplished!

What is it good for:

Some of you may ask what's the advantage of this over more complex tools like JMeter or LoadRunner , for example. For one thing, this allows you to very easily spread out your tests to multiple hosts, rather than having to do everything from one. For some of you it will derive even more value and give you yet another reason to show your boss how good an idea it was to set up that CloudBees Accelerator build farm. This will also work with the free-to-use CloudBees Accelerator Huddle , giving small teams access to a powerful testing mechanism. Another very important point to consider is that you very likely already have a number of homegrown tools that your team has developed and used over time, but which most likely lack two important aspects: automation and scalability . ElectricCommander can give you automation, and the above technique will give you scalability. *Image credit: Dare by Gisela Giardino on Flickr.