I’ve been posting lately about a tool named bonnie++, which will run a suite of tests against your linux filesystem to determine metrics in 3 important areas:  data read/write speed, max random seeks, and max metadata operations.  Last time I posted about profiling one of Linode.com’s “Linode 360″ instances.  In this article I will profile a m1.small instance on Amazon Web Services’ (AWS) Elastic Compute Cloud (EC2) service.

EC2 is the first legitimate cloud offering to market, and in many contexts they are the most developed, most robust, cloud provider.  However, there are many companies quickly ramping up their offerings (GoGrid, Voxel, Flexiscale, etc), if only in one or two datacenters (Voxel is the leader of the group, with locations in NY, Singapore, and Amsterdam).

The m1.small instance comes with the following specifications:

• 1.7gb RAM
• 1 EC2 Compute Unit
• 160gb instance storage
• “moderate” I/O performance

While these specs are mostly useful in comparison to other EC2 instance sizes, the performance of this particular size will provide a useful benchmark for baselining EC2 performance.  Since this is the smallest instance, I’m assuming “moderate I/O performance” means that it’s as bad as it gets.

From the earlier post, we use the following command to invoke bonnie++:

# bonnie++ -u 0 -r 1700 -s 34000 -n 256 -b -d /

The above commanded failed to run, claiming that the filesystem was out of space.  Checking the filesystem, I see that I only have /dev/sda1, which is 15gb and mounted at /.  Since real-world testing involves what the customer actually gets and not what the marketing literature says, I adjusted the -S parameter to 3400, which should easily outpace/outpage the 1.7gb of memory in my instance.

Invoking bonnie++ with the new parameter yields me with the following result (click for larger image):

Server ip-10-226-125-238 was able to

• sustain ~52MBS at 6% CPU for sequential block writes
• sustain ~64MBS at 1% CPU for sequential block reads
• max out at 939.8 random seeks per second
• sequentially create 127 files per second
• randomly create 174 files per second
• sequentially read metadata from 158,584 files per second at 39% CPU
• randomly read metadata from 203,851 files per second at 41% CPU
• sequentially delete 121 files per second
• randomly delete 158 files per second

As the results from running bonnie++ in various providers pile up, I will compile them into a spreadsheet which will (hopefully) ultimately shed some light on the performance boundaries of various VPS and cloud providers.

• Previous Entry: Linode filesystem performance
• Next Entry: Creating custom TCP monitors in Nagios