Cloud / VPS Apache Performance Comparison

UPDATE #1: I received several comments about the testing methodology used in these benchmarks so I wanted to explain further. Each server instance at the Rackspace Cloud, Linode and Amazon are running the exact same Linux distribution (Debian 5.0 Lenny), kernel, architecture (x86_64) and version of Apache (2.2.9 w/ worker MPM).

UPDATE #2: After much concern was raised I went ahead and reran the benchmarks on the small instances after tuning a few settings on the Linode server.

echo 99999 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

Also, instead of running the tests from a consistent remote location I ran them on the local machines this way I could guarantee that network latency wouldn’t impact the test results in any way.


In the past few weeks there has been a lot of talk about the differences between various Cloud and VPS providers (see my post), mainly revolving around performance. I decided to take some time last week to run some very straight forward and real world tests to gauge performance among the most popular providers: The Rackspace Cloud, Amazon EC2 and Linode.

For the benchmark I decided to use ApacheBench and Siege as *most* users on these platforms are serving some type of web content via Apache. Even if different web server software is used, it is unlikely that the results and trends would differ. As part of a series of posts, I will be running the same benchmarks against static content and dynamic content. This way we can be sure to look fairly at all aspects of each particular platform.

As mentioned, I decided to use ApacheBench and Siege as the testing platforms so I performed a default install of Apache 2.2 with the Worker MPM on each server instance. The server OS platform is Debian 5.0 Lenny on all servers.

These benchmarks are very easy to duplicate, so if you would like to test the results simply replicate the total connections or time and concurrency settings mentioned below.

I did not tweak any of the Apache settings on any of the server instances. I used the default settings of:

<IfModule mpm_worker_module>
StartServers                             2
MaxClients                              150
MinSpareThreads                  25
MaxSpareThreads                 75
ThreadsPerChild                    25
MaxRequestsPerChild          0

I ran the same tests against each platform and since I was only hitting the default HTML page generated by the Apache install I decided to raise the concurrency limit up to something significant to generate some real load. Each benchmark was run three times over three different days and I took the best result from each set of tests.

ApacheBench: 100,000 Total Connections / 100 Concurrent Connections
Siege: 10 Minutes Under Siege / 50 Concurrent Connections

Let’s get to the results!

Small Size Instances

ApacheBench Results

Rackspace 256MB Cloud Server Linode 360MB Media Temple DV 512
Concurrency Level 100 100 100
Requests [#/sec] (average) 10,706.64 4,554.43 N/A
Time Per Request [ms] (mean) 9.340 21.957 N/A
Transfer Rate [Kbytes/sec] Received 3336.14 1,414.39 N/A

Siege Results

Rackspace 256MB Cloud Server Linode 360MB Media Temple DV 512
Transactions 1,587,997 1,165,412 N/A
Availability 100.00% 100.00% N/A
Response Time 0.04 secs 0.05 secs N/A
Transaction Rate 2,647.68 trans/sec 1,942.90   trans/sec N/A
Successful Transactions 1,587,997 1,165,412 N/A
Failed Transactions 0 0 N/A
Longest Transaction 0.42 0.61 N/A
Shortest Transaction 0.00 0.00 N/A


The Rackspace Cloud Server instance, with only 256 MB of RAM, performed well under the stress as did the Linode 360 server, but there is still a significant difference in the overall performance. This could be due to host server utilization, but according to the Linode control panel the host machine my instance was running on is “low”.

In the Siege results we get some similar insights. The 256 MB Rackspace Cloud Server processed significantly more transactions than the Linode server. Importantly, the transaction rate was also much higher.

There is always a lot of discussion around the Linode 360 server instance being a better value than the 256 MB Rackspace Cloud Server, but the tests show otherwise. In my opinion this is most likely due to Rackspace Cloud’s lower utilization of host hardware and a more robust network.

Large Size Instances

Now lets take a look at the larger instances. I wanted to work Amazon’s EC2 platform into these performance tests and their large instance is most comparable to the Cloud Server and Linode instances of the 8GB variety.

ApacheBench Results

Rackspace 8192MB Cloud Server Linode 8640MB Amazon EC2 Large
Concurrency Level 100 100 100
Requests [#/sec] (average) 10,729.61 9,109.91 6,782.93
Time Per Request [ms] (average) 9.320 10.977 14.743
Transfer Rate [Kbytes/sec] Received 3,363.62 2,829.17 2,113.04

Siege Results

Rackspace 8192MB Cloud Server Linode 8640MB Amazon EC2 Large
Transactions 1,564,152 1,636,652 891,956
Availability 100.00% 100.00% 100.00%
Response Time 0.04 secs 0.04 secs 0.07   secs
Transaction Rate 2,606.79 trans/sec 2,727.34   trans/sec 1,485.80   trans/sec
Successful Transactions 1,564,152 1,636,652 891,956
Failed Transactions 0 0 0
Longest Transaction 0.49 0.22 0.65
Shortest Transaction 0.00 0.00 0.00


As we saw with the smaller instances in the ApacheBench test, the Cloud Server with fewer resources is outpacing both the Linode server and the Large EC2 instance. But in the Siege benchmark we see the Linode instance take the crown for total transaction rate. I would note the larger memory allocation on the Linode server instance might have something to do with these results so be sure to compare price for your particular application.

Amazon’s Large EC2 instance was the slowest of the bunch during the ApacheBench testing but did complete all of the transactions thrown at it during the Siege benchmark.

Final Thoughts

The tests show some significant performance benefits when running on the Rackspace Cloud Servers platform on the low end and similar performance to larger Linode and Amazon instances on the high end even though the comparable Cloud Server had much less memory and therefore lower cost. In my opinion, I believe lower hardware utilization and better host server hardware contribute to these results.

Apache settings can definitely be tweaked to increase performance on any of these platforms; this was just a baseline test using the defaults provided. The next round of tests will focus on serving a dynamic web applications.

If you have any thoughts, questions or comments about the benchmarks performed here please leave a comment below. I’d love to hear from you!

[VIDEO] Installing Drupal 6 on Cloud Sites

Yesterday I posted a video tutorial covering how to install WordPress on the Rackspace Cloud Sites platform. This video was a huge hit so I wanted to put together another one showing another extremely popular platform deployed onto Cloud Sites, Drupal.

I’ve used Drupal personally for many years on various projects and it is by far my favorite CMS platform for a variety of reasons, most of which revolve around the massive community. Watch the video for a step-by-step walk through with some quick performance notes as well which will ensure your Drupal site runs and scales smoothly within the Cloud and uses as few resources along the way as possible.

If you have any feedback or ideas for other video tutorials please leave me a comment or drop me a line on Twitter (@ckeck).

Get the Flash Player to see this content.

Mosso Cloud Sites & Media Temple GS – Put To The Test

Strong web site performance, reliability, and uptime – these are all traits you would expect from an enterprise-class Cloud hosting platform, right? That is exactly how I feel now – and exactly what I expected almost three years ago when I started looking at the very early cloud hosting platforms of the time.

My name is Chad and today I am a Mosso employee. Long before I joined the Mosso team, however, I enjoyed (sometimes) hosting many of my own web sites and those of friends, colleagues, family, etc. Back in late 2006 I was looking for a better platform for the sites I hosted. I was tired of trying to manage my own solution, and I was frustrated with the downtime and poor support of all the VPS providers I had used over the years. Cloud hosting was a very new concept and, in fact, I don’t think it was even referred to as “cloud” just yet, but there were two main providers in this space at that time: Mosso & Media Temple. Like many, I was concerned about the initial concepts but very intrigued with the technology so I splurged and purchased hosting accounts both with Mosso and with the Media Temple Grid platform. I decided to do some testing on two basic fronts: response time & uptime. As you may have figured by now, one platform excelled in comparison, and I was so intrigued that I ended up coming to work for Mosso!

So now, in early 2009, I thought, “Why not duplicate those same tests and see what the results would be?” And that is exactly what I did. I set up identical static web sites serving a 100KB image and identical dynamic sites, a vanilla WordPress 2.7.1 install on both platforms (Cloud Sites from Mosso and Grid-Service from Media Temple). Next I decided to leverage Pingdom for all the testing, as they have a wide variety of testing locations around the world. These tests for uptime and response time were performed via a full HTTP check (not ping) and occurred in 1 minute and 5 minute intervals on different copies of the static and dynamic sites. I set the test to run during the middle of a typical business week and collected roughly 72 hours of data.

The results were very impressive. Uptime percentages for Mosso Cloud Sites were a solid 100% compared to about 99.0% on average with Media Temple GS, and downtime stuck solid to zero seconds, while Media Temple was down 1-5 times across the different test sites resulting in almost 30 minutes of downtime on average per site. Average response times for Mosso Cloud Sites were at least half of that of MT GS, with Cloud Sites sometimes operating almost as much as five times faster!

This test is easy to duplicate if you would like to try it firsthand. If you have any questions, please do not hesitate to contact me. Please see the results below and you can see the direct Pingdom reports here: