Why Rails really can scale

There have been a number of posts throughout the community recently talking about scaling Rails. Of course this has been an endlessly debated issue for years now, but it is coming back to the forefront thanks to news like Blaine Cook’s recent departure from Twitter (and Twitter’s many other recent issues). I feel it’s time to throw my two cents in on the matter.

First a little background: I’ve deployed countless Rails applications, from tiny deployments with a single VPS to several 10+ server setups. For those who scoff and say that 10 machines is small…they’re probably right, but not everyone can be as lucky as Twitter. But these sites are all easily capable of handling multi-million pageviews per day, which is enough for 99.9% of the sites on the web.

Now to begin with, let’s talk about why Rails is GREAT at scaling:

1. Rails has a very clean line between what belongs on the ‘web’ server and
what belongs on the ‘app’ server.
A lot of people have a major problem with the fact that Rails can’t be served by a typical web server (like Apache + mod_php or IIS/ASP). But the truth is that as soon as you grow beyond two servers, it
becomes a great benefit to have a clear and easy to follow line about what the web server’s job is and what the app server’s job is. It’s easy to delegate responsibilities to the correct server that can do the best job and this separation is of instant benefit. For those who still don’t like it: Passenger/mod_rails is making great strides.

2. Rails can scale out very easily.
Adding additional app servers is very easy, thanks to the fact that you must already have a reverse proxy set up. And the scaling is about as linear as it comes. The app servers and web servers are already ‘share-nothing’ (besides maybe the caching)…so it is common sense & almost second nature to add more boxes as needed. For more info, see It’s boring to scale with Rails.

So where did Rails get this bad rap about scaling?

I suspect it comes from two issues:

1. Ruby is slow.
ActiveRecord is slow. Rails is not-fast. This really has nothing to do with scaling. All together, this means that to handle a given load, you will need more hardware than a comparable app written in Perl or PHP. This issue is about giving up a piece of performance to get a much larger piece of productivity & maintainability
2. RDBMS’s do not scale well.
AHA! We run into the largest problem most people have and where a lot of the argument seems to stem from. Eventually, you will expand to the point where your one little MySQL box just can’t handle it any more. It is absolutely saturated and we start having all sorts of problems.MySQL is not terribly easy to scale. Postgres isn’t much better. This is not Rails’ fault. Of course, it doesn’t matter whose fault it is, if Rails needs a database and your database doesn’t scale, then there’s a definite problem. Fortunately, there are plenty of things that you can do to deal with these problems.

In the very near future, I’ll talk about the two things that you can do to turn Rails into the best-scaling framework out there.

Leave a Reply

Your email address will not be published. Required fields are marked *