Scalability Testing in the Cloud using Amazon EC2

One of the biggest challenges during the development of SQL Monitor v2.0 was to effectively test its ability to scale with a large number of monitored servers. On the surface this would appear easy as a large number of Red Gate employees have machines that run one or more instances of SQL Server.  We actually did do a fair amount of performance testing in this manner but we also felt the need to do something from scratch where we could have total control over the number of machines online and the precise load they are under.


I had written some dubious code that generated activity on a specific server, but we needed about 50 or so servers on which we could do this.  Now at Red Gate we have infrastructure that allows us to fire up Virtual Machines but the general feeling was that this would definitely not be able to cope with the kind of activity I had in mind. This is when I started looking at Amazon EC2, a “resizable compute capacity in the cloud” to quote the Amazon blurb. The idea is that you launch an AMI (Amazon Machine Image) on one of Amazon’s huge server farms and pay a small price per hour. This seemed ideal for the testing I had in mind so I’ll get on and tell you a bit about how I got started.

First port of call is the Amazon Management Console.


This is a good place to start – easy to use and you can get an instance up and running pretty soon. A couple of annoyances quickly become apparent. The first launch of any ready-to-use AMI can take up to 15 minutes whilst it queries for the Administrator password. However, if you create and re-use your own AMIs, the launch time is reduced to a few minutes. The second issue is the limited number of Windows operating systems supported. They support 2003 and 2008 Server which isn’t great if you want to use EC2 for more general Windows OS testing but for scalability testing it’s probably good enough.

The Amazon Management Console is a good start but it’s not long until the sluggish speed and session timeouts start to get annoying. This was when I migrated to Elasticfox, a Firefox plug-in that from a usability perspective is generally superior to the default Amazon offering. It’s quick, doesn’t time-out and has loads of context menu options that can really speed things up.  The only downside I’ve found is that it doesn’t seem to support CloudWatch, an extremely useful service that monitors the performance of your machine instances.


There are probably other management consoles out there due to Amazon Web Services basically being a bunch of web services with a very easy to use API. Once I’d discovered this, most of my subsequent AMI management was done using Visual Studio and NUnit drivers to start / shutdown machine instances. Once I had created several personal AMIs, the IDs could be hardcoded into the C# project and I never had to think about it again.

I found it very easy to create networks on EC2 and even the automate this. To do this I first launch a domain controller VM and then send the IP address of this machine to all subsequently launched machines. I have modified all of my personal AMIs to contain start-up code that will read in the IP Address of the domain controller and automatically join the domain. As automatic network creation on EC2 is quite a large subject I’ll be covering this in part two, Setting up Windows Networking on EC2.

This entry was posted in Testing. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Required fields are marked *

Add an Image


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>