2

I've been trying to gather all the pieces together for setting up a load-balanced cluster of three servers (2 for Web nodes and one for MySQL) as a LAMP stack on EC2. This is only to run performance tests on an application, and I need to gather the appropriate information so that I can estimate the time it will take. I was wondering if someone could fill in the blanks for me about the following:

What exactly is a compute unit? I'm looking at needing three mirror instances of RightScale's AWS CentOS, two as Web nodes and one with a database. Do I need three small instances then?

If I'm using Apache as my Web server, is mod_proxy the best way to load balance on Amazon's EC2? I see Amazon has a load balancer that can be configured to work with Amazon CloudWatch to provide metrics. Is that a better way to go?

For application caching I want to use memcache. Any issues with this on Amazon's EC2? I'm thinking of using Siege (http://www.joedog.org/index/siege-faq) to do my stress testing. Does Amazon provide something already to do stress testing, or would this be an appropriate tool?

For someone like myself who has no experience using this service, aside from installing our application on both of the Web nodes, what sort of time are we looking at here? I'm familiar mostly with deploying applications on server instances and have some experience with server configurations and performance tuning, but I'm a programmer by trade. I'm thinking 30 hours for setup, and then probably another 15-20 for testing. Does that sound in the ballpark?

Improve this question

3 Answers 3

Reset to default
2

As mentioned, a compute unit is roughly an older 1.0-1.2 ghz server-class processor, and you'll want to consider Amazon's Elastic Load Balancing.

For a simple load balanced LAMP stack, you should start with a small instance type and work up from there based on your testing and benchmarking.

memcached works fine on EC2, but you'll need to consider the volatile nature of EC2 (instances can go down w/o warning at times).

Starting from scratch with no configuration management (you didn't mention anything so I'll assume none, but I like Chef), you're looking at probably at about 2 work-weeks. Always over estimate, as EC2 can be... finicky to work with.

I also suggest using the EC2 API tools (even better is a library for your favorite programming language) so you can programmatically control your instances.

Improve this answer
1
  • When we tried ELB, we found that it does not support the HTTP-100 CONTINUE header. That was a show stopper for us.
    – Eric J.
    Sep 29, 2009 at 20:07
1

If your only planning on running the machines for a short while, you can probably simplify a lot of things and avoid using Amazon's elastic block store. What this means is your files won't be persisted on shutdown or a crash. If you don't shutdown your instances, it's unlikely they will crash, or you'll lose your data. You wouldn't want to do this in production, but for testing it should be fine.

For a load balancer, simply use Amazon's Elastic Load Balancing. Use Amazon's if your planning to run with a hardware load balancer in your production setup. If in production you plan to use a software load balancer - then yes, use the same one on the EC2.

For testing, I like to do low level http tests with httperf. For application level testing I like to use JMeter. Usually, I'm doing the testing the other way around though. I run JMeter on EC2, and have that test load on my non-EC2 data center. That way I'm doing a complete end-to-end test. However, I'm guessing your doing your test because you don't have the extra hardware locally to run a mock production setup.

Improve this answer

You must log in to answer this question.