Are Twitter's performance problems due to flimsy engineering or the choice of Ruby on Rails to build the application?
In the Twitter developer blog on Thursday, an engineer said that Ruby on Rails still rocks as a Web development platform. The service's woes are due more to a creaky architecture, he said.
Twitter performance problems have broughtfrom the busy Web 2.0 digerati. That has prompted the company to disclose like today's Q and A format blog.
Many people have questioned whether choosing to write the application using Ruby on Rails was a smart move and whether Twitter should shift to a different Web development technology.
Ruby is a scripting, or dynamic, language, which means that it can be slower than Java or C for some applications. The trade-off is that in general it's faster to write code with. Rails, meanwhile, is a Web development framework optimized for speed.
Ruby still makes sense for much of what Twitter does--essentially sending messages around the Web--but the company has left the door open to using other languages. The Twitter developer blog says this:
We've got a ton of code in Ruby, and we'll continue to develop in Ruby with Rails for our front-end work for some time. There's plenty to do in our system that Ruby is a great fit for, and other places where different languages and technologies are a better fit. Our key problems have been primarily architectural and growing our infrastructure to keep up with our growth. Working in Ruby has been, in our experience, a trade-off between developer speed/productivity and VM speed/instrumentation/visibility.
The outages and slow performance are due to "popular" members of Twitter with many followers who "tweet" a lot all at once, according to Twitter. Because of that, the company says will put some limits on what some users can do, but it should not be noticeable.
We have some limits, and we're adding more. Legitimate users should never notice them, but these new limits should help mitigate the worst case failures and attacks.