Just over a week's gone by and the community is still buzzing with the Rails scalability debate. Developers are asking the defining question: does Twitter prove Rails can't scale?
Twitter is an ad-hoc messaging service originally intended to allow users to update their friends with what they were doing. The status system very quickly changed to ubiquitous conversation - via web, im and sms, with echoes of IRC spread throughout. Coupled with the addition of bots - most notably CNN and BBC feeds being piped through to twitter users - and you're left with a very busy application.
So when Alex Payne - a twitter developer - spoke about scaling their app last week, the first real "can Rails scale?" questions began to surface. This led to an expected fury of commentary from many different corners of the web.
So what really is going on? Alex commented that "there shouldn't be doubt in anybody's mind at this point that Ruby itself is slow." This has since been countered by other commentators, but it's still understood that Ruby isn't the fastest language out there.
Alex goes further, and comments on specific issues with the Rails framework. He highlights the need for more efficient templates (to reduce compute time) as well as multiple database access methods within ActiveRecord. He points out that "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."
With the debate truly sparked, Rails creator David Heinemeier Hansson reacted on his weblog, criticizing the Twitter team for having "forsaken [the opportunity to fix it] for an arms-crossed alternative", suggesting instead that the development team are only interested in playing the "blame game".
Reactions have been varied. Many developers and commentators have provided their 'insight' with very little practical outcome. Hansson refers to Magic Multi Connections, a plugin for ActiveRecord as being the tool to solve twitter's problems. Hansson comments: "Williams let code be his reply to the discussion of Twitter's woes on scaling the database. I would of course rather have seen this work come out of Twitter, but I'm happy that they got a free offering handed to them regardless."
In response, Blaine Cook - twitter developer - told us that he thinks "Dr. Nic's approach is a great first step, and adds some welcome helpers to selecting from a number of database connections." but noted that "Twitter isn't currently database bound, and won't be for a while yet". Regarding the problem of scaling Twitter, Blaine points out that "at high levels of traffic, it's really about scaling the application, not the framework. The thing that I love about Rails is that it's flexible enough to let us focus on Twitter and our users."
This prompted to ask him how busy Twitter really is. After some checking, Blaine told us that currently Twitter is serving upwards of 600 r/s - not the 11,000 misquoted by Hansson. Though they are confident that they will reach the 11,000 figure soon enough.
Debate still continues in comment threads and private communities, with some in the community advocating a less aggressive community response. The Twitter team are still relentlessly battling their performance woes. Blaine will be speaking at SDForum this weekend about some of these topics, which is sure to be a packed session. Let's not forget, one the biggest web-applications right now - facebook.com - serves 17,000 req/s. That's almost thirty times more than Twitter.
Dr. Nic, author of the Magic Multi Connections plugin adds "The guys at Twitter have already contributed code to Ruby community (Jabber API), and when they settle on a solution for their situation, I think they will be very happy to share it with us. That will be great. Remember: Rails is 2 years old. .NET + ISS is 7+ years old. Java is 10 years old. LAMP is very old. So, its all in front of us. Exciting times."