Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I created a web application using NGINX, Rails, and MySQL. Currently they are all running on a single VPS (Slicehost). I've followed best practices and maintained a very minimal 'shared-nothing-architecture' with the idea that if I need to scale, I'll simply ramp up a few more slices to meet demand.

With the idea that I am trying to keep costs as low as possible, what would be a good strategy for bringing on additional slices on an as needed basis? My initial thoughts are that I should run 3 VPSs. Two for databases in a master/slave configuration, and one for NGINX/Rails. As load increases, ramp up other NGINX/Rails servers as required with the original server handling the load balancing to the other servers.

You thoughts?

share|improve this question
up vote 1 down vote accepted

This has been covered in a variety of other posts. In general:

1) Use a tool like chef or puppet for sys config mgmt.

2) Use a tool like fabric or what not for code deployment.

For the above...these are not to be underestimated...scaling in a reproducible manner is key.

3) You might want to split off a server (or servers) for simple static serving (images) if you're not using a CDN.

4) As to the DBs vs app servers, do you know how your application bottlenecks? If not, stress test it. Figure out where it's bottlenecking under several different common scenarios and base your capacity planning on that. Plan on how to shard out your DB (multiple copies based on keys for example). Plan on how to distribute / load balance your incoming traffic.

To keep things cheap you can test a lot of this on something like amazon for much cheaper than VPSes like slicehost (paying for the hours / days to scale up DB shards or application servers vs. paying for a month of a VPS you might not use much).

You can even run the stress tests from inside EC2 to keep the traffic costs minimal.

share|improve this answer

In addition to ironchef's comments, I'd make sure that your high-availability load balancing infrastructure is working well before you need it; this means either using Slicehost's provided load balancing right from the beginning (if they have a product like that available) or having two "frontend" slices with the load balancer HA-shared between them right from the start. You do not want to be hurriedly throwing on a load balancer when you're getting pummeled with traffic, especially since it looks like you're not particularly experienced with this sort of thing already.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.