More on Twitter, Rails, and Scaling

Just a brief update to point to some more good discussion on the issues with scaling Twitter to handle its load better, as discussed in my earlier post on Friction(less) Rails. The first thing I wanted to point out is that a lot of people have called Twitter’s purported load into question. The original source for the 11,000 requests/second number was DHH’s original post as far as I can tell. That’s a heck of a lot of load, and as others have pointed out, its a nice problem to have. Jens Alfke of Apple has written a nice post describing the problem and ways to handle it that do not involve databases. Its an interesting read, and the comments are worth a look as well.

Another article worth reading is by Peter Bell. In it, he reflects on the tone of the conversation to date and thinks about the appropriateness of Rails for the applications it is being used for. I don’t actually agree with him but its an interesting point of view:

Simple apps with huge traffic requirements needs different engineering choices that complex enterprise apps that may have lower loads but higher complexities and maintenance burdens. When I look at an app like twitter (which is when it comes down to it, a submit form, a list display and an API along with some really interesting scaling challenges) I’m not sure Ruby or Rails would be the ideal tools. I’m not sure what language has the very best support for the highest and most robust levels of performance and scalability, but I’m guessing whatever it is would be the perfect choice – even if it meant it took you a week instead of a day to code the form, the API and the list (I know it is a little more than that, but I think we all know it doesn’t need to be TOO much more than that – it isn’t exactly an insurance quoting app or something).

As with anything cool and new (remember when Java was the *it* language?!) Ruby and Rails are being widely misused. I am not convinced that all of the Web 2.0 start ups selecting Ruby have picked the bet tool – they’ve picked the coolest one. However, cool tools bring the smartest programmers so it still may be a smart decision – even if the language and framework has problems, at least choosing them means you can more easily get the most innovative programmers to work on your problems, and just like in Venture Capital where a good team trumps a good idea, in programming a good coder trumps a good language.

Once again, I want to commend people for turning the conversation in a more positive direction. Its been a great read.

Advertisements

~ by Andrew Shebanow on 19Apr07.

2 Responses to “More on Twitter, Rails, and Scaling”

  1. Thanks for the mention :->

    Just in case the conversation *does* take a downturn again, I’m not saying Rails or Ruby can’t scale. Only questioning the choice of a language and framework designed to speed development at the cost of performance for an application where performance rather than speed of development is probably the main driver!

    Personally I’d prototype Twitter in *insert-cool-dynamic-language-here* and then if performance was an issue, once the interfaces were pretty well locked I’d get a second team to re-code the app using a more performance oriented stack.

    I develop a lot using ColdFusion which blends the benefits of dynamic typing with enough OO support, a great set of tag libs and a built in templating language for both templating views and code gen (which is what I’m usually doing).

    I wouldn’t hesitate to prototype in CF and then have a team port some or all of an app to a different language if performance was way more important than how quickly I could add new features.

  2. […] saw an interesting update on the Twitter story. One of the best parts though was the link they provided to this […]

Comments are closed.

 
%d bloggers like this: