

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

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. :-))<p>Our basic aim is to ensure maximum availability at minimum possible cost. :-)<p>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:<p>1. http and php<p>2. mysql<p>3. images<p>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).<p>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.<p>(Naturally, we'll optimize HTML/CSS, PHP code, MySQL config, table structures, queries etc. to the max.)<p>What do HNers with relevant experience think of this plan? What changes would you suggest? What are we missing?<p>Please share your views.
======
petervandijck
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.

------
gspyrou
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>

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

------
sagacity
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.

------
bmelton
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.

