-1

I was contracted to make a groupon-clone website for my client. It was done in PHP with MYSQL and I plan to host it on an Amazon EC2 server. My client warned me that he will be email blasting to about 10k customers so my site needs to be able to handle that surge of clicks from those emails. I have two questions:

1) Which Amazon server instance should I choose? Right now I am on a Small instance, I wonder if I should upgrade it to a Large instance for the week of the email blast?

2) What are the configurations that need to be set for a LAMP server. For example, does Amazon server, Apache, PHP, or MySQL have a maximum-connections limit that I should adjust?

Thanks

James Gu
  • 195
  • 1
  • 1
  • 3
  • 2
    Why blast them all out in 1 go? Why not spread the emails (and the load) over a week period? – AliGibbs Dec 15 '11 at 17:29
  • There are mail blasting services that are dedicated to this sort of thing -- They are good at moving large volumes of mail quickly, and the good ones have relationships with major freemail providers like google/yahoo/hotmail and RBL providers. You should investigate one of these – voretaq7 Jan 14 '12 at 05:40

2 Answers2

1

It isn't really possible to give a definitive answer without detailed usage and load patterns on your server, but some ideas that might be of use to you:

It is likely that not every one will open their email at the same instant - so you can probably presume that those 10k hits will be distributed over some time. Also, I presume that the emails are all being sent at once to give people an equal opportunity at whatever you are offering.

For the architecture aspect: I would recommend Amazon's Linux as the operating system - it is fairly stripped down, has a low memory footprint, includes fairly recent packages in its repository, and performs well. Favour a 32-bit operating system for the instances with under 3GB of RAM.

I would suggest nginx over Apache for a high load server with FastCGI (using php-fpm). This should allow you to handle more concurrent connections than Apache, with lower resource usage. Definitely setup an opcode cache (e.g. APC) if your content is highly dynamic.

Cache whatever content you can - especially if all your visitors are going to be seeing the same thing (e.g. a coupon/advertisement). Varnish is a good option (although, if you go with nginx, it does have the ability to do some caching, although it does not offer the options of Varnish). Depending on the nature of your content, you may even consider generating a static copy and serving it off S3/Cloudfront.

If possible, you may want to consider putting your database on a separate server so that you can use autoscaling to scale your webserver if demand exceeds your expectations. You may also want to use spot instances to complement your main server(s).

You may find it beneficial to offload some of the content (e.g. images) to Cloudfront - depending on the bottlenecks of your setup, this could greatly reduce the network and disk usage of your server (keeping in mind that small instances have 'moderate' I/O). If you have a disk bottleneck, you may consider setting up multiple EBS volumes in a RAID to improve performance.

Also, keep in mind that it is fairly easy to scale vertically from a small instance to a large instance on EC2 (although, the typical approach does have a couple minutes of downtime, this can probably be avoided).

As @uesp suggested, you definitely want to load test your server. If you have many different pages that will be accessed, you can setup a URL list and have siege randomly access these - which will offer somewhat realistic indications of performance.

cyberx86
  • 20,805
  • 1
  • 62
  • 81
0

There is, unfortunately, no one answer as it depends on your application (what you are serving) and the exact traffic (is it just one page load per customer or 100s, 10k in 5 minutes or 24 hours). For example, a complex unoptimized Ruby app connected to a large unoptimized database will need a huge amount of resources while a simple static HTML/image could be served with a single lighttpd server running on a low end server.

If you have your app setup on a server already what you can/should do is benchmark your system using something ab (ApacheBench), siege or any other similar program. To get a rough upper bound on your performance run it on the local server to eliminate network performance. Depending on your app you may need specific test setup, like setting cookies/session information to properly gauge the performance. You may also want to test different parts of your app (static/dynamic, slow/fast, logged in/out, etc...) if applicable.

After testing you should have some rough numbers on the traffic you can handle and, from there, decide whether a larger system is needed or not. Testing should also reveal if you need to adjust any app/server parameters like a connection limit as well as help gauge the effectiveness of parameter tweaking.

In the end, though, it is always a trade off between cost and performance and you have to decide how much performance you need as well as how much you're willing to pay.

uesp
  • 3,414
  • 1
  • 18
  • 16