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!

  • Pingback: Cloud / VPS Apache Performance Comparison | Chad Keck DOT Com «

  • Pingback: Cloud / VPS Apache Performance Comparison | Chad Keck DOT Com «

  • Pingback: Cloud / VPS Apache Performance Comparison | Chad Keck DOT Com «

  • Pingback: Cloud / VPS Apache Performance Comparison | Chad Keck DOT Com «

  • Pingback: Cloud / VPS Apache Performance Comparison | Chad Keck DOT Com «

  • If you would like to test the (mt) service, you should get a (gs) Grid Server. The (dv) Dedicated Server is not setup as a “cloud” but rather a virtualized instance on a single machine. Your tests results will most likely be a bit different. I hope this helps!

    Michael Handa
    Support Supervisor
    (mt) Media Temple

    • Hey Michael,

      The reason I chose the MediaTemple DV server is because the other platforms in the comparison are virtual machines running on a single physical host very similar to the DV server. I will be doing some future performance benchmarks between the Rackspace Cloud Sites platform and the MediaTemple GS service as these are very similar platforms. Thanks for commenting and feel free to chime in anytime, take care.

  • bd_

    The reason apachebench failed for you on Linode is likely due to a conservative default setting for the ip_conntrack limits. Try doing this before the benchmark:

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

    This shouldn’t be necessary under normal loads, just for benchmarks that spin up huge numbers of connections in a very short interval. Increasing it may result in increased memory usage for conntrack, however.

    • Thanks for the insight, but I wanted to run the tests without any special customization on any of the server configurations. I’m sure there are countless tweaks that could be made across the OS and Apache itself to improve performance, but out of the box with the same settings as the others it wasn’t able to handle 100 concurrent connections to a simple HTML page.

      Maybe I can do a second round of tests making this same change across the board.

  • Pingback: uberVU - social comments()

  • The Linux kernels’s default connection tracking table size is too small for a benchmark like this. You can increase the table size with:

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

    Running the benchmark after making this change provided 100% transaction response rate in our tests. We’ll be increasing the default in our next kernel release.

    Thomas Asaro

    • Thomas,

      I’ll go ahead and make the same changes to all platforms and rerun the benchmarks. Thanks for the input — I want this to be as objective and fair as possible.

  • Justin

    Hi Chad – in the ‘Medium Size’ section, the table headers say Rackspace 256MB – that should probably be 1024MB. I think it would be very interesting to include the instance prices as well! If a Rackspace 1024 performs better than an EC2 1700MB, that makes Rackspace cheaper (at least for this web benchmark), which is interesting because most people believe EC2 is the cheapest around.

    • Justin,

      Thank you for pointing that out, that was indeed a typo and the server instance used in the ‘Medium Instance’ testing was a 1024MB Cloud Server.

  • Ross


    Don’t you think you should be letting everyone know you are a RackSpace employee, this test seems highly biased and should be removed.

    • Ross,

      I have it posted in many areas of my blog that I am a Rackspace employee, but I went ahead and added a disclaimer at the top of this post to there is no confusion. These tests are not biased in any way towards Rackspace and I have to respectfully decline on removing this post. Thank you for reading and commenting.

  • Vincent


    When I ran these benchmarks against my Linode 360 running Debian 5 Lenny 64-bit, Apache 2.2, static page, just like you did, I averaged 1,984 requests per second and 504 ms per req. I applied the kernel connection tracking fix others have pointed out.

    I looked at the kernel source, and the setting Linode uses is the default in the 2.6 kernel with no changes. Its a safe bet that Rackspace’s platform should have failed too, unless the kernel default has been altered. I’m keen to think you fixed it on your platform quietly while writing the review and saw an opportunity to claim the tests failed elsewhere, but you deserve the benefit of the doubt…

    My question is, are we going to see updated numbers for Linode, even if they’re detrimental to your original point?

    • Vincent,

      It’s unfortunate that there is no way for me to directly prove that I made no modifications to the Rackspace Cloud Server, but if you want to in fact test if I am being honest and transparent you can easily spin up a 256MB Cloud Server and see that it will complete the benchmarks easily without the need to make any modifications as you mentioned above. I would never tarnish my reputation over something so minor.

      Also, as I mentioned in another comment, I will make some of the tweaks suggested to the Linode and even the Media Temple DV server as well as the Rackspace Cloud Server and rerun the tests just so we have another consistent report. You will not see updated numbers for Linode and Media Temple in this post as “out of the box” it failed the tests, I cannot go back and change that. It failed 3/3 times. I will make a new post with the updated results after the tweaks are made to each server.

  • Vincent

    Sorry, I read the ab output wrong — that’s 0.504 ms/req, not 504 ms/req

  • (I are not the above Ross.)

    I’m glad to see you benchmarked more than one VPS from each provider… unlike the fella who published benchmarks of several companies a few weeks ago and his choice to use a whopping sample size of one. Silliness!

    Though perhaps for your next round of benchmarks you could use, say, three VPSs of each tested size… doing so may rule out a highly loaded host server and the sort. Just a thought.

    • Hey Ross,

      Thanks for the kind words — I specifically tested more than one size instance so we could see how the performance would trend. One sample size is far too limited in scope.

      And as you mentioned, I will be testing a few more of the similar sized instances and posting the results here. I want these tests to be as accurate as possible. This is also why I’ve run the tests multiple times at different times of day and taken the best results from each. Not just one round of testing. With any Xen based platform you will undoubtedly run into high load on the host servers at some point which can really skew the results.

  • Vincent

    Why not put the updated results here? You told the Linode employee above you wanted to be objective and fair…

    Your reluctance to put the results here makes me think you dont want to give visibility to how well Linode will do since Rackspace tweeted this post. Prove me wrong?

    • Not sure where you are going with this Vincent. I stated I would do another entire post with the server OS tweaks across all the platforms which will give full visibility into Linode’s performance, but I am not going to remove the results from this previous benchmark because their kernel implementation isn’t set up properly to handle larger number of concurrent connections on their smallest instance.

      Why should I completely replace the current results if I am going to do another post? Not trying to be rude but you just aren’t making sense IMHO. I’ll give full visibility to Linode even if they beat out the comparable Cloud Server.

  • Malcolm

    It seems to me that this test was fatally flawed from the beginning and was designed to make Rackspace look good. You used Apache Bench settings that would fail on most any system out of the box.

    To make matters worse, you are a Rackspace employee showing that Rackspace is the only system even slightly capable of performing the targeted test. Regardless of how accurate this test may be you are biased and the test results will always show that. I have no doubt that you chose to run a test that you knew would perform well on a Rackspace cloud server.

    Your unwillingness to set the ip_conntrack_max limit to the same on all hosts and update the results on this post just further shows that you are a shill for Rackspace. I find it rather disappointing that Rackspace feels so threatened that it is necessary for such an empty marketing post with false tests and engineered results.

    • Malcolm,

      I’m going to be very direct and blunt with you because I don’t know how many times I have to explain myself here.

      How are the ApacheBench settings I used a for sure failure on any system out of the box? These were not predetermined numbers, I researched many ApacheBench articles and this was a common test I found so I used it.

      My being a Rackspace employee has nothing to do with the results. If you cared to read the entire article you would have noticed that the 1024MB Cloud Server and 1080 Linode both easily completed the performance test and with relatively close results. Did I fudge that one too? I did no prior research or studies beforehand to know how this test would perform on a Cloud Server, but you will believe what you want to believe.

      As I already mentioned to Vincent I will update the ip_conntrack_max limit on ALL the server instances including the Media Temple DV server and re-run the tests and post the results, but I WILL NOT change or delete the results from the “out of box” testing nor should I.

      Rackspace does not feel threatened by anyone or any provider, and let me further clarify that this is not a Rackspace sponsored post or test. This is something I did on my own time with my own resources as I was consistently asked how the small Rackspace Cloud Server instance stacks up to similar platforms.

      These tests are not false simply because you do not like the results, sorry. Stay tuned for the updated benchmarks as I’ve mentioned I would do about 5 times already.

  • Malcolm

    What exactly were you trying to test? The hardware performance? Since you used tweaked values on the RS server and distro/kernel (not provider) defaults on the rest it obviously can’t be hardware. Distro performance? Nope, you used multiple distros as well. Did you even use the same architecture?

    I’m not complaining about the results, I’m complaining about the test methodology. “Out of the box” is a marketing term only with no actual information behind it. If you are looking to demonstrate the actual performance of the various nodes then you need to reduce the number of variables as much as you can. Multiple distros can drastically alter the results for a test like this. Tweaked parameters vs defaults will alter the results as well.

    You work for RS (as you previously stated) but in your initial post there was no mention of that. It’s pretty hard to believe results that favor your employer when no effort was made to disclose the fact that they are your employer.

    • Malcom,

      Yes, am demonstrating performance of the host servers running these virtual machines and what a typical user can expect to see in terms of performance. I did not “tweak” any values on the Rackspace server so I would appreciate if you quick making false accusations unless you know otherwise. This is one of these things you can verify on your own, just spin a server up real quick and find out. Just like I told Vincent, I’d be more than happy to cover the $0.25 it will cost you for a few hours or day.

      The same exact distro and architecture (64 bit) were used on the Rackspace Cloud, Linode and Amazon EC2. The only provider that used a different distro was Media Temple which I had no control over.

      And “out of the box” is not a marketing term when the *majority* of users aren’t going to know how to tweak kernel values to make the server like it should, OUT OF THE BOX. This is exactly why I tested it this way and not by tuning these servers to no end.

      I didn’t disclose I worked for Rackspace inside the post itself because I thought the 5 other places I mentioned it was enough (About Me page, footer, etc). Don’t make it out like I attempted to cover the fact that I work for Rackspace when anyone who looked at my site for more than 15 seconds could have easily figured that out.

  • Vincent

    Why should I completely replace the current results if I am going to do another post? Not trying to be rude but you just aren’t making sense IMHO. I’ll give full visibility to Linode even if they beat out the comparable Cloud Server.

    Because you made sure you logged on to @rackcloud and retweeted yourself earlier today. Will you do the same when Linode or (mt) comes out ahead? No. That’s why you want to do a separate post so that it can dwindle away without the fanfare, Hackernews attention, and so on.

    Look at it from an outsider’s perspective…Linode gets mega attention with a well-planned & long-researched set of benchmarks and you had to respond in kind…Eivind’s benchmarks showed that Linode kicks Rackspace’s ass and (as Malcolm points out) you now feel threatened enough to toot your horn. I know you were a sales rep when Rackcloud was still Mosso, so it’s forgiveable.

    The fact is the people you are trying to sway see right past it, and judge the data for what it is. We are not idiots. When I removed network from the equation and ran ab against localhost instead of over the network, my Linode 360 almost did 10,000 rps. Any comparison can be swayed in any direction the writer wants it to and you are ensuring that the correct data will never be published because Linode ‘failed’ (by not altering a tunable kernel variable)

    There’s two options here, either (1) Rackspace performed so badly that the limit was never hit or (2) the limit was altered ahead of time to sway the results…it’s not rocket science. If (1) is true, lucky you, you skated by with subpar performance. If (2) is true, everything youre saying about not altering the platform is a lie because somebody changed a kernel default either in your distribution of Linux or after the fact and during the review. You repeatedly say that Linode and (mt) failed the test “3 out of 3” and you won’t change it after the fact to stay “pure” but you’re really comparing apples and oranges…

    You are making Rackspace look like a toddler crying for attention, simply because Linode got good press recently…and you are doing badly.

    • Vincent,

      I wonder what your stake in this is. You sure are making a lot of assumptions about me and this performance test. The kicker is they are all inaccurate. And thanks for the laugh, the next time an independent performance test comes out showing Rackspace on top I’m going to ask Linode and Media Temple to post it on their blogs and tweet about it, right (are you listening to youself?).

      The simple fact is that anyone can run these tests and verify the data. Why don’t you go ahead and to that? If its the $0.25 its going to cost you I’d be more than happy to make sure you don’t get charged. I am 100% confident that anyone who runs these tests on their own will end up with the same or consistent results.

      I’m not going to continue to feed a troll either. Your false assumptions about Rackspace performing badly or someone altering the kernel default are just that, false. So while I “re-do” the tests after having to tweak Linode’s default image, why don’t you go ahead and run these tests independently on your own as well?

      You also still continue to ignore the fact that the results on the larger instances were much better for both Rackspace Cloud Servers and Linode and that the results are very close. Why would I sabotage the tests on the smaller instances and not the larger ones as well? Oh thats right, maybe because I am telling the truth. Accept it, and if you can’t, do it yourself.

      •  The point is that this is not an independent test. It is not run by an independent person. IF you are an employee of Rackspace (looks like it), then it is not independent by default. Stop kidding yourself. What is your stake in this? it is huge, because you are EMPLOYED by Rackspace and would stand to gain when Rackspace is better.

        BTW, I don’t use either system. But I know a thing or two about conflict of Interest.

        • Actually it was an independent test. It was done outside of Rackspace and unsanctioned.

          All of this is irrelevant however because as I made very clear, the tests were easily repeatable by anyone. There is a reason the results aren’t directly disputed and that is because (at the time) anyone who replicated the benchmarks would have gotten the same or very similar results.

          My stake in this? None. I don’t even work for Rackspace anymore. But none of that changes the data and facts. I didn’t ask anyone to take my word either. These were just my results and if you don’t believe them test yourself. Until then why even bother commenting?

          I’m not so sure you know much about conflict of interest in this context either, sorry. Thanks for the note though. I’m happy to see this post is still controversial after all this time.

    • Updated the numbers exactly as you requested Vincent, in the same post too. I even went so far as to take out all the verbiage about the prior tests failing. Also removed network out of the equation as well. Your thoughts now?

  • Dude


  • Malcolm

    Can you please define what “Test failed” means for ab? Unless every single connection of the 100,000 attempts failed then the test didn’t fail. If every single connection did fail then you did something very wrong as many people run web servers successfully on the smallest Linode and Media Temple instances including myself.

  • David

    There are a lot of accusations here, I don’t understand why because from what I can see it seems like these tests were done clearly and he is being transparent.

    I am new to vps recently moving my business sites to consolidate, so I don’t have a whole lot experience with any of it but I am always looking to see what is the best to use.

    I can agree with that out of the box testing is the way to go…if you can dispute these show them to me. i want to have a host that will perform really well right away i really dont have time to figure out how to tweak servers it should just go yes?

    I am an outsider here myself and as I see it some of you are being childish, i see linode got press but so what they arent the only ones to have some. dont be jealous just disprove him then. that other benchmarks you talk about didnt show me what this is showing so I cant just go off that either, since I rely on apache heavily that what found me to this.

    I await those new tests and everyone elses as well.

  • Malcolm

    I was planning on running the comparison myself but I’m still waiting for RS cloud to activate my account. I placed the order over half an hour ago and still haven’t received the phone call I’m supposed to get “within 15 minutes of your order”.

    • Email me the username or email address you signed up with and I’ll make sure your account gets put in active status ASAP.

      chad [at] chadkeck [dot] com

  • Malcolm

    At the risk of sounding like a total ass, can you run the same test from your AT&T connection again? Local system tests aren’t real world and don’t do a whole lot to demonstrate the performance of a server. Also, can you put the original results table back in? It would be nice to have a point of reference.

    By the way, I did get my account activated shortly after I posted my earlier comment. I’ve been running many tests and hope to publish the results shortly.

    • At the risk of sounding like a total ass, can you run the same test from your AT&T connection again? Local system tests aren’t real world and don’t do a whole lot to demonstrate the performance of a server. Also, can you put the original results table back in? It would be nice to have a point of reference.

      Thought this is what you and Vincent were asking for? Only took me several hours last night to redo everything :) I guess I can do it *again* from my home internet connection but its probably not going to be today. I’ll get the other data back up in some form as well.

      I look forward to seeing the results from your tests as well. I am confident that they will be inline with my initial results and as you should have found already, no tweaks are needed on the Cloud Server. And thank you for taking the time to run some of these tests on your own as well, it would be nice to have someone verify.

  • Vincent

    Are you kidding? I got exactly what I wanted…surprised you haven’t realized that yet.

  • I like happy endings. :3

  • Vala_Home

    Hey guys, why don’t you give the guy a break and trust him he’s being sincere in his testing even if he works for Rackspace employee. I had a bit of contact with the Rackspace Cloud people and they can hardly be taken as liars.

  • When you are one of the best in the world at something you will always find people that want to tear you down. I’ve worked with Chad before, he is a straight shooter and a very honest person. Perhaps a dose of maturity is needed here. After all, if Chad really wanted to mislead the public he certainly would not have posted troll-ish comments from people that obviously have a bone to pick with Rackspace.

  • Troll Cannon

    The results of this benchmark and all associated comments were very conclusive: trolls do indeed exist on the internet!

  • I’m not techie to the extreme of running such tests as you have. I am however, an active reseller/user of MediaTemple, Rackspace and Amazon.

    I have found that the Rackspace servers are much more economical and offer more bang for the buck vs Amazon. Not to mention the ease of getting support.

    MediaTemple however, I have found to be VERY stable. Perhaps more so than the Rackspace CloudSites (but then again I’m comparing the MT’s $20/month offering to RS CloudSites $100/month) offering.

    I like both, MT wins on the Control Panel, it is very well design and user friendly, however, on scalability, RS CloudSites is definitely where I place my money.


  • HD

    I think your research is excellent and very well explained. It was a fair comparison and all variables were equal. Thanks for sharing Chad.
    Well done.

  • Pingback: かなり気になる ScalOut 関連記事 6本 « Agile Cat — Azure & Hadoop — Talking Book()

  • Pingback: Daily Digest for December 23rd « Alex Bilbie()

  • Thanks for the comparison, I found it very accurate. I also came upon similiar results when testing several VPS and cloud service providers.

  • Anonib

    Where’s the update? I keep seeing this AstroTurf comparison promoted on Twitter as updated, but it’s been stale since last year.

    • Anonib,

      I updated the post and some of the results shortly after posting due to several complaints that I “jobbed” the competitors platforms. If you read the UPDATES you will see what I changed.

  • Sue

    Where is the ‘like’ button? Great article, thanks. I am just starting out with Rackspace after having used GoGrid and I am it’s worlds of difference better. I’ve become an evangelist for Rackspace. Please e-mail me if there are any consumer sites where I can give you five stars and say nice things.

  • Pingback: Cloud / VPS Apache Performance Comparison | Chad Keck - Virtual Private Servers()

  • Protip: don’t call BS on someone else’s figures, and then ask them to spend hours of their free time re-running tests you could easily do yourself. Especially if you’ve decided not to trust their results anyway.

    Chad, thanks for the benchmarks – it gave me a good feel for how the various size offerings are likely to behave. Will do my own testing (which will me cost maybe a dollar) before committing to one, suggest others do the same. Sheesh.

    • chad

      You’re certainly welcome Dick. I’m glad you found the information here helpful.

      Would love to know what type of results you see if you run similar tests. Take care.

  • Pingback: Aimlessly wandering from Rackspace Cloud Servers to Amazon AWS; a WordPress mu perspective | Niccolo Favari()

  • Sorry for the late post I know this is almost a year old but about a month ago I did tests on Rackspace, Godaddy, and EC2. I came out with similar results. EC2 finished last for server hardware, but had a faster network. Godaddy had far faster hard drives than rackspace(about 4x faster). But rackspace had faster CPU and memory operations.

    • Thanks Mike for the feedback on your recent tests, appreciate the insight.

  • Great Work You made some good points there..Thanks 

%d bloggers like this: