With the "Cloud" being in vogue currently, we see a lot of clients asking for cloud solutions, mostly Amazon AWS. Sadly, this is normally done without really doing a proper evaluation into whether the cost is reasonable, or the technology is suitable for their specific needs.

Amazon AWS provides some unique and compelling features. Among those are: instant provisioning of virtual servers, billing for used resources only, ability to provision more instances on demand, a wide variety of instance types, and much more.

We certainly like Amazon AWS for development and testing work, and for specific use cases such as seasonal sites.

For most high traffic sites though, Amazon AWS can be overly expensive, and not performant enough.

Before you decide to use Amazon, spend some time studying the various Amazon instance types, and the pricing that will be incurred. You may be surprised!

Here is a case study of a client that was on Amazon until recently, and we moved them to a more custom setup, with great results.

The client is a specialized news site, and gets linked to often from other high traffic sites such as Yahoo's front page, and the Drudge Report.

The site was originally hosted at another big name hosting company, but unfortunately they went down several times due to data center power issues.

After moving to Amazon AWS, with the setup below, the site was a bit sluggish, and when the traffic spikes described above happened, the setup could not cope with the increased traffic load ...

Amazon AWS Setup

The setup relied on Amazon's Elastic Load Balancer (ELB) front ending the site.

Behind the load balancer, there were a total of 4 instances, varying in type.

First, there were two web servers, each one of them m1.large.

Another m1.small instance acted as the NFS server for both web servers.

Finally another m1.large instance housed the MySQL database.

To summarize:

2 x web servers (each m1.large)
1 x MySQL database server (m1.large)
1 x NFS server (m1.small)

The cost was high compared to the features: EC2 computing cost alone for the instances was around $920 per month.

Additionally, there were 331 million I/O requests costing $36 per month. ELB was an additional $21 per month.

Storage and bandwidth brought the total to $990 per month.

Setup Drawbacks

The drawbacks of such a setup are many:

First, there is complexity: there are many components here, and each required patching with security updates, monitoring of disk space and performance, and other administration tasks.

Second, it was not fault tolerant. The only part that is redundant is the web server, with two of them present. However, if there is a database server or NFS server crash, the entire setup would stop serving pages.

Third, the cost is too high compared to a single well configured server, at almost half the cost.

Fourth, Amazon's ELB Load balancer forces the "www." prefix for the site, which is not a big deal for most sites, but some want to be known without that prefix.

Fifth, the performance was not up to par. The site was sluggish most of the time.

Finally, the setup was not able to handle traffic spikes adequately.

The Solution

After doing a full Drupal site performance assessment, 2bits.com recommended and implemented a new setup consisting of a single medium sized dedicated server for $536 per month.

The server is quad core Xeons E5620 at 2.4GHz, 8GB of RAM, 4 disks (each 2 forming a mirror).

We then did a full server installation, configuration, tuning and optimization tuning the entire LAMP stack from scratch, on our recommended Ubuntu 8.04 LTS Server Edition. Instead of using Varnish, we used only memcached.

The setup is mostly like what we did for another much higher traffic site. You can read the details at: 2.8 million page views per day: 70 million per month: one server!

After consulting with the client, we recommended to go a step further and use the additional budget, and implement a near fault tolerant setup. The second server is in another data center, and the monthly cost is $464.

The Results

The results is that we now have a satisfied client, happy with the new setup that is free of the headaches that they used to face when traffic spikes happen.

Here are the graphs showing a large spike in July 2010.

Two traffic spikes in Google Analytics. The traffic shot up from the normal 81,000 to 83,000 page views per day, to 244,000. The spike on July 12th was 179,000 page views.

Apache accesses per second, by day

Apache volume per second, by day

CPU utilization per day, no noticable spike

Memcache utilization, showing that it took most of the load

Impact on Google Site Speed Metric

Some time back Google started tracking site speed in Analytics.

Here is one Drupal site that moved from a single dedicated server to an Amazon AWS cluster. The same code base is now slower in "the cloud". The site was around 250 milliseconds for Server Response Time. After the switch on April 25th, that response time doubled to 500 milliseconds, with spikes of near 1 second.

Lessons Learned

There are lots of good lessons learned from
A performance assessment is valuable before deciding what hosting to use. This will give a baseline and reveal any bottlenecks that your site may have.

In most cases, we advocate simplicity over complexity. Start simple and then go add complexity when and where needed.

Try to make the most of vertical scaling, before you go horizontal.

Amazon AWS is great for development and specific use cases. It may not be your most cost effective option for high traffic sites though.

Memcache, used properly, will get you far on your journey to scalability and performance.

Further reading

There are lots of links on the web about Amazon AWS and hosting LAMP on it.

Here are a select few recent Drupal specific presentations and podcasts:

Articles
Drupal Planet
Drupal Performance
Dedicated Servers
Amazon AWS
EC2
ELB

Comments

Visitor (not verified)

Sat, 2010/08/07 - 15:19

As I know you're aware, Amazon's EC2 product is nowhere near competitive in terms of processing power or support. Linode and Rackspace Cloud give far, far better bang for the buck and they give excellent support for free.

Amazon offers *fantastic* features, and is constantly raising the bar. Why they're not competitive on actual processor power is beyond me.

I just wanted to clarify that what Amazon EC2 can do is not necessarily representative of "the cloud".

Khalid

Sat, 2010/08/07 - 23:22

Randy,

I agree that Amazon EC2 is not competitive in compute power pricing. That was the gist of my article.

However, there are a few other points.

First, "cloud" is more of a marketing term, and is otherwise ill defined as a technology term. It used to mean just virtualized servers, but as it stands now, there is no standard definition, and no cross vendor standards for protocol or API to make things comparable. It is always up to the specific vendor to define cloud as X or Y or Z. Until such a standard definition and standard API/protocol is widely accepted, there will be no way to compare objectively.

Second, with abstraction and multiple layers, there is always opaqueness and ambiguity. More often than not, when you choose cloud, you choose convenience over performance. You never know where the disks are and what is between you and the disks. It will always be slower than bare metal, and will always be less predictable. Add to that high cost, and you should really think twice (or more) before putting a high traffic site on any cloud platform.

The least one could do is some homework in benchmarking the setup before committing to it. It is more expense upfront, but it is better than nasty surprises down the road.

Visitor (not verified)

Sat, 2010/08/07 - 16:41

Excellent post and great illustration of the issues at hand.

What a lot of people miss is that cloud hosting is just another form of shared hosting with all its attendant issues, such as indeterminate latency, nasty neighbors, etc. In contrast, dedicated servers have a lot to offer, especially in terms of guaranteed performance, both latency and throughput.

If any readers are at DrupalCampLA come to my session tomorrow afternnon and spar with me over the merits of cloud vs. well designed dedicated servers.

Visitor (not verified)

Wed, 2010/08/11 - 08:44

You assert in your article that Amazon AWS could not do the job with 3 large instances and one small, and that replacing it with a single server was more cost-effective, but the article does not go into the problems associated with the Amazon setup.

After all, the single-server dedicated replacement had a similar spec to only one of the Amazon large instances, so surely the site could have been consolidated onto a single instance on Amazon, rather than going dedicated?

If not, why wouldn't that be an option? Is it because Amazon does not have the I/O capacity during the traffic spikes? If so, is there a graph or some statistics to demonstrate this? Without this kind of information, the article could be summed up as "it's better to use a single dedicated server than four Amazon instances, but we'd like you just to believe that," but I'm sure there is more behind the decision to make the move than that.

Supposing it was simply poor configuration that was causing the Amazon setup to be sluggish, and one well-configured Amazon instance would have done the job. It looks like the single Amazon instance would have been the cheaper option?

Khalid

Wed, 2010/08/11 - 14:10

The driving force behind the move was that the particular Amazon configuration was both costly and performed poorly.

Amazon AWS EC2 offers High CPU Extra Large instances. A single instance of that is $497.76 for compute time alone. We need to add the cost of storage and bandwidth to that.

Moreover, such instances do not offer I/O performance comparable to a dedicated server with fast disks with low latency, and the ability to distribute the load to many disks in a precise and granular manner. We do not know how the disks at Amazon are connected, nor who is sharing them with you.

There is also some overhead due to virtualization, and your neighbors on the same physical hardware.

With a dedicated server, you don't have any of that, and it is cheaper, and more predictable too ...

Jaap Haagmans (not verified)

Tue, 2013/07/30 - 10:17

The I/O performance of an EBS volume is currently actually comparable to a physical SATA disk. Do mind that the underlying hardware is in fact a physical disk, but it appears to be a 1 TB disk, meaning that if you use 20 GB EBS volumes, you could be sharing the physical disk underneath with lots of other people, also drawing on its I/O performance. Furthermore, latency will be higher than a physical connection to the disk.

To eliminate the I/O issue, it's possible to make use of guaranteed I/O capabilities, but that's a costly option for most of us. It's also possible to use only 1 TB EBS volumes (eliminating multi-tenancy) and perform striping using software RAID. Striping should of course only be used on setups with high fault tolerance on an instance level.

Khalid

Mon, 2010/08/16 - 12:02

For the sake of completeness, I should mention that there is a way to reduce Amazon on-going hosting costs by using reserved instances.

Instead of paying $497 per month for compute time only, it could be down to $176. However, you have to pay $1,820 upfront for a 1 year term, or $2,800 for a 3 year term in order to get that lower rate.

Obviously, this is a long term commitment with all the drawbacks that such an agreement entails. If the site is mature and not experiencing growth anymore, then this may be an acceptable option. If the site is still growing then committing to this may not be a good idea.

Always do the math and evaluate other options such as dedicated servers, especially an overall cost analysis, not just monthly costs.

Azaz (not verified)

Wed, 2016/03/09 - 06:24

AWS is a great option for hosting Drupal application. However, AWS is a little tricky for those who do not have experience in system administration or setting up servers. But there are services like Cloudways that provide platform for installing and managing Drupal application on cloud.

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting