5 Question Interview with Twitter Developer Alex Payne

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.

5 Question Interview with Twitter Developer Alex Payne

About this entry