Thought

Moving to Mecury Migrating this site from DreamHost to the Cloud.

I have always dreamed of going into space. I often ask people if they would go out into space if given the chance; I think it gives a small bit of insight into someone's personality. I doubt I will be able to make it into space in my lifetime, though I think it'll be close. But, if I can't go, this site can still move to Mercury.

Pretty cheesy intro, I know. What this actually means is that I just moved this site from being hosted at DreamHost to Amazon Cloud AWS with Chapter Three's Pantheon Mercury. The main reason to do this was performance, but I will discuss the pros and cons of this switch below.

Performance

I have done some very basic benchmarking with AB (Apache Benchmarking). By no means is this a rigorous test, but it does add some insight into the performance increase. I ran ab from a third-party server that had more consistent bandwidth and each test is for the homepage; I am running a small (default) instance. A very rough way to read all this is to say I get 50x the performance with Mercury.

Test and Metric DreamHost Mercury Increase
ab -n 100 -c 10
  Failed requests 29 0 ~2,900%
  Requests per second 0.98 19.81 2,021%
  Time per request 1024.6ms 50.490ms 2,029%
ab -n 1000 -c 10
  Failed requests 321 0 ~32,100%
  Requests per second 0.87 41.09 4,723%
  Time per request 1150.489ms 24.335ms 4,728%
ab -n 1000 -c 50
  Failed requests 7 0 ~700%
  Requests per second 44.86 112.15 250%
  Time per request 22.292ms 8.916ms 250%
Average
  Failed requests 119 0 ~11,900%
  Requests per second 15.57 57.68 370%
  Time per request 732.46ms 21.91ms 3,343%
Increase average 5,204%

What is Mercury?

Mercury is a set of server configurations, most commonly in the form of an AMI, that creates a web host for a Drupal site that focuses on performance and uses other technologies such as Pressflow, Varnish, and Apache Solr.

In a more basic sense, if you wanted to set up a server to host a Drupal site and you wanted to get the most performance out of it (as if someone didn't want to); Mercury does all the initial configurations for you.

Why Mercury?

Well, obviously the performance is a big deal. But in reality, this blog doesn't see that much traffic, so there are other reasons as well. Overall, its the combination of AWS and Mercury.

I wanted control, but I am lazy. I now have complete control over the server that my site lives on, for better or for worse. This is a big change form DreamHost as I was just a small user on a big server there. The control and flexibility is great. But I also don't want to spend a lot of time doing systems administration for my blog, hence why I had chosen DreamHost in the first place. But Mercury provides a great middle ground: it supports the cloud infrastructure giving me the flexibility of my own server, but it does all the hard parts of configuring the server to host a Drupal website.

Why DreamHost?

I still like DreamHost. I think they are a good company and offer some of the best services for their price range. I have heard a lot of different opinions about DreamHost but I still stand by them.

For your 5 USD a month you get a fancy interface with lots of goodies and lots of features, and practically unlimited space and transfer rates (though it doesn't work out to be as good as it sounds). They also give you lots of control over your account considering that it is shared hosting.

Making the Switch

Overall, this was really easy. As this was my first use of AWS, most of my time was just figuring out the basics of the cloud. Here are the rough steps to migrating a site (see this documentation).

  1. Backup your site and database.
  2. Create AWS account.
  3. Make Key Pair.
  4. Create an instance with the Mercury AMI.
  5. Log into the instance and read the included /root/README.txt file. For those new to AWS, you have to use your key pair file to ssh in, for instance: ssh -i /path/to/local/pem/file root@public.dns.for.your.instance
  6. The default site is found at /var/www/, I would suggest copying this somewhere just in case.
  7. Create a root password for MySQL. Set up a new database and put in your database dump.
  8. Copy your files, modules, and themes over the existing site.
  9. Update settings.php.
  10. Run Druapl update: drush updb
  11. This should do it. Use your public DNS for your instance to view the site.
  12. Set up an Elastic IP (a.k.a. dedicated IP) and update DNS and other things as needed.

Final Thought

Overall, Mercury is awesome and really takes out a huge amount of work in setting up an environment for Drupal with some great services that focuses on performance and I can really tell the difference in making the switch.

Do note, I have switched from an environment where I don't have to worry about much, to having to know about it all. Don't try to switch to AWS and Mercury unless you know how to set up a web server from scratch; Pantheon may do a lot of the heavy lifting, but there is no GUI for it. If you are not that technical, go with hosting that takes care of these things. If you have the knowledge and the resources, definitely use Mercury to get the most performance out of Drupal.

Comments

Thank you for taking the time to write this up. I have been tempted by Mercury, but am currently running a cPanel VPS that I can happily administer through a GUI. That last line of caution in your article is right on the money.

it's not an apples to apples comparison. You went from shared hosting to a VPS. PRetty big difference just there alone.

These are wonderful instructions, and we soon hope to have more options for people looking for a more "traditional" environment (e.g. linode stackscripts, rackspace, etc) so they don't necessarily have to tackle the EC2 learning curve at the same time.

Two questions:

  1. From where are you running AB? Locally (e.g the server is benchmarking itself) or remote? If remote, what is the speed of the network connection?
  2. Have you tried running a test with a larger number of requests (the -n parameter)? Even 1000 isn't all that much at a concurrency 50, and you'll get more interesting/accurate numbers if you let it run for 10 or 20k hits. Of course, if you're doing this remote and paying for bandwidth, this might cost you a few dollars, so don't do it on my account. :)

Anyway, I'm really pleased to see this is working out for you, and thanks a million for posting the helpful migration instructions.

Thanks for the kind words, Josh. I ran AB from a third party server on SliceHost; I am not entirely sure of the bandwidth limitations, but I figured it would be a consistent place to test from.

I have actually already made the DNS switch and don't have the best of options to keep fully testing this further. My goal with this basic testing was just to show a quick metric on how much performance increased with the switch. Also, to give a solid third-party, unbiased, practical example of the performance increase. I'll do more rigorous testing if/when I move some other sites.

well i am still on shared hosting but was looking forwards for an VPS for my growing hosting needs.Thanks for this post as now it will helpme to make some decisions on hosting in future

It has been some months since the move, did you consider updating the article, or writing a new one, to let us know how do you feel about it now?

Also, if you don't mind could you put a line on pricing - of course everyone should do their own analysis, but if you have any non-obvious insight it would be much appreciated (or simple bottom line comment).