Ask HN: Stack/Hosting plan for a viral social web app | Hacker News Reader

Ask HN: Stack/Hosting plan for a viral social web app

6 pointssagacity5 comments

We are preparing to launch a social web 2.0 app that has a strong potential to go viral. (We already know that the chances of our app going actually viral are probably slim to nil; so be kind and spare us the scepticism. :-))

Our basic aim is to ensure maximum availability at minimum possible cost. :-)

The app (nearing completion but not quite there yet) is built on PHP/MySQL/Java/AJAX and there will be 3 major load factors associated with it:

1. http and php

2. mysql

3. images

We're planning to deploy 3 VPS accounts/servers, one for each of the above 3. We're thinking of having all 3 VPSes in the same data centre (with unique IPs).

We believe this will provide not only load-distribution benefits but also the ability to upgrade just the VPS that may be causing slowdown/outage in case of a sudden traffic burst, at relatively low costs.

(Naturally, we'll optimize HTML/CSS, PHP code, MySQL config, table structures, queries etc. to the max.)

What do HNers with relevant experience think of this plan? What changes would you suggest? What are we missing?

Please share your views.

Here's one approach on AWS.

Put http and php on an ec2 instance. Crank up as needed. 1 really big server can take quite a bit of traffic. Plan to add load balancing too (or add it straight in). Add memcached layer to take it easy on the db.

Put mysql on an RDS server. Crank up to 68 GB of memory, 26 ECUs as needed. This will most likely be your bottleneck, but memcached should help a lot, and optimize your queries. Later on you can add slave drives and such, but one big server (and memcached) should last you a while.

Put images on a separate subdomain, on S3.

(Also, put all static files like js and css on another separate subdomain on S3.)

Instead of pre-optimizing everything to the max, just use sensible settings and install really good monitoring tools. Then, fix bottlenecks as they happen. The main thing to optimize before launching are your queries, I wouldn't worry too much about the rest, they'd just give you 10, 20% improvements etc., whereas queries can give you 1000% improvements.

You could try Windows Azure . http://ecn.channel9.msdn.com/o9/mix/10/mp4/SVC12.mp4

http://ecn.channel9.msdn.com/o9/mix/10/mp4/EX23.mp4

Have you checked Rackspace cloud? They are extremely cheap comparing to other cloud-based solutions.

Thanks for all the input - peter, gspyrou, codingstaff.

Please keep more of it coming - I'm sure it'll help us (for now) and it'll also help many others.

As already mentioned -- the images are cheap to fix. Stick 'em up on S3 (with or without CDN), and they'll almost certainly be fine.

General HTTP isn't something we can really answer for you. If your PHP is memory intensive, there's a different remediation plan than if it's more CPU intensive. Regardless, you want to be leveraging a cache wherever you can. For the most part, unless you're excessively out of the norm on either memory or CPU, you'll likely be fine on a fairly small instance, so long as you abstract the DB away from there.

Versus petervandijck's advice, I would recommend a number of smaller, load balanced EC2 instances instead of one big EC2 instance. It might add a little bit of complexity, but if you start off load balancing an $11 a month micro instance, it's easier to spin up additional instances as you need them, while keeping your base cost low. Alternately, you could of course spin up an $80 a month instance, and have less to worry about on the higher end, but it also costs more even if you aren't under load.

As for the database, I'll leave that to my betters, but memcached is your friend.

Reply on news.ycombinator.com