Twitter blaming Ruby on Rails for failures?
April 12, 2007
Twitter has become quite a popular application and as a result the system is fielding more than 11,000 requests per second across some 16 cores. The result? The service feels slow as hell. Turns out the Twitter folks, specifically Alex Payne, is placing the blame squarly on the Ruby on Rails framework. Alex explains in an interview with Josh Kezner,
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.
David Hansson responds by suggesting that the Twitter folks might be a little lazy. In prior conversations with the Twitter team David explains their plan to scale the application, "It sounded like they had a good plan at the time, though. Roll in a rack of new servers, look into doing substantial caching, and move beyond a single database server. The normal road to sanity employed by most any web application experiencing rapid growth." David is concerned that Alex Payne is afraid of hard work, i.e. the hard work of scaling any popular application. Alex explained, "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."
David is obviously taking Twitter’s comments about Rails personally. But instead of simply complaining he explains how problems, such as the one faced by Twitter can present an opportunity for the entire community.
Second, when you work with open source and you discover new requirements not met by the software, it’s your shining opportunity to give something back. Rather than just sit around idle waiting for some vendor to fix your problems, you get the unique chance of being a steward of your own destiny. To become a participant in the community rather than a mere spectator. This is especially true with frameworks like Rails that are implemented in high-level languages like Ruby. The barriers to contribution are exceptionally low.
In this case, it seems that Twitter requires more sophisticated ways of talking to many databases at the same time. Alex puts it a little black and white with "…there’s no facility in Rails to talk to more than one database at a time", which isn’t really true, but it could definitely be done better. Last I spoke with Twitter, we discussed this and they sounded enthusiastic about being able to further this area of Rails. It’s disappointing to hear that they’ve forsaken that opportunity for an arms-crossed alternative.
In any case, I’m proud that Twitter is having to push the envelope on scaling Rails. Fielding 11,000+ requests per second is no small feat for any dynamic web application. Once the stress of having to deal with that in the moment subsides, I’m convinced that the team will grow beyond the blame game, get their hands dirty as full participants in an open source community, and contribute back their advances to the framework. We’ll all be richer for it.
