Press "Enter" to skip to content

scaling ruby on rails

I’ve had a few conversations lately with people about Ruby on Rails as a development framework. My understanding (as a non-programmer): “it’s a fantastic and flexible way to build a new webapp, but scaling might be an issue.” The Rails fans I know say, nonsense.

Well, Twitter is apparently the busiest Rails site on the net, and here is what they have to say about it:

2. How has Ruby on Rails been holding up to the increased load?
By various metrics Twitter is the biggest Rails site on the net right
now. Running on Rails has forced us to deal with scaling issues –
issues that any growing site eventually contends with – far sooner
than I think we would on another framework.

The common wisdom in the Rails community at this time is that scaling
Rails is a matter of cost: just throw more CPUs at it. The problem
is that more instances of Rails (running as part of a Mongrel
cluster, in our case) means more requests to your database. At this
point in time there’s no facility in Rails to talk to more than one
database at a time. The solutions to this are caching the hell out
of everything and setting up multiple read-only slave databases,
neither of which are quick fixes to implement. So it’s not just
cost, it’s time, and time is that much more precious when people can[’t]
reach your site.

None of these scaling approaches are as fun and easy as developing
for Rails. All the convenience methods and syntactical sugar that
makes Rails such a pleasure for coders ends up being absolutely
punishing, performance-wise. Once you hit a certain threshold of
traffic, either you need to strip out all the costly neat stuff that
Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move
the slow parts of your application out of Rails, or both.

It’s also worth mentioning that there shouldn’t be doubt in anybody’s
mind at this point that Ruby itself is slow. It’s great that people
are hard at work on faster implementations of the language, but right
now, it’s tough. If you’re looking to deploy a big web application
and you’re language-agnostic, realize that the same operation in Ruby
will take less time in Python. All of us working on Twitter are big
Ruby fans, but I think it’s worth being frank that this isn’t one of
those relativistic language issues. Ruby is slow.

See the rest of the interview: here.

(from Pat)


  1. heri heri 2007-04-13

    i think any technology or framework would have problems handling twitter’s usage

    twitter is an ‘extreme’ example and most web projects will stumble upon other problems before having a problem with RoR

  2. Hugh Hugh 2007-04-14

    chris: thanks for the link, i know 37signals, but didn’t know they wrote a book.

    heri: i think you are right, any framework has its ups & downs. but it’s good to know where one of rails’ downs is…namely:

    “At this point in time there’s no facility in Rails to talk to more than one
    database at a time.”

  3. Josh Josh 2007-04-20

    The Twitter experience was definitely interesting to read especially from the scaling perspective.

    Current Ruby is relatively slow so the scaling translates into more necessary hardware power. However, Ruby 2.0 will include the YARV virtual machine and be much faster (IBM Toronto software Labs’ Antonio Cangiano did a comparison of an early Ruby 2.0 trunk). Here, one should allow some time for Ruby on Rails using Ruby 2.0 to be stabilized. But the future perspectives are still astounding.

    The best thing with Ruby and RoR currently is the speed of development and the ease of maintainance. That means that it is still wickedly easy to prototype, grow and maintain Web 2.0 apps using RoR. that a major advantage.

Comments are closed.