是Twitter不努力，还是Rails本身有问题？

虽然已经过去了一个星期，社区里仍蔓延着Rails可伸缩性问题的讨论，很多开发者还在打破砂锅问到底：Web 2.0新贵Twitter证明了Rails难以伸缩吗?

Twitter是一个ad-hoc(一种无线互连对等网络结构) 实时信息服务网站，它最初的目的是让使用者的朋友及时地知道该使用者正在做什么。通过IRC传播回应的方式，这个状态系统能以Web、IM和SMS的方式快速地形成会话。结合自动代理，绝大多数优秀的CNN和BBC种子会传给Twitter用户。

所以当Alex Payne ，Twitter的开发者之一，在上星期介绍他们的应用伸缩性问题时，第一个“Rails是否具有伸缩性？” 的现实问题就浮现出来。从而导致了一场预料之中的激烈评论，这些评论来自于网上-许多-不同-的-地方。

实际上是怎么回事呢？Alex 评论说“在每个人的脑海里，有一点是无可置疑的，那就是Ruby 本身就慢。” 此言一出就引起了很多评论者的反对，但不得不承认Ruby不是运行速度最快的语言。

Alex进一步地评论了一些 Rails框架具体的问题。他强调说Rails需要更高效的模板（为了减少计算时间），同时也需要能通过ActiveRecord访问多个数据库的方法。他还指出“一旦你遇到某些流量瓶颈问题时，要么你把Rails自带的（如RJS、ActiveRecord、ActiveSupport等）性能代价较大的部分整体移除掉，或者不用Rails实现你应用中速度慢的部分，又或者两种方法同时使用”。  

随着争论开始真正擦出火花，Rails 的创始人David Heinemeier Hansson 在他的blog上反击，批评Twitter开发团队不珍惜自己修补的机会，翘着双手看戏，暗示说Twitter开发团队只是把责任推卸到别人身上而已。

每个人的反应都不一样。许多开发者和评论者都提供了自己所谓的“见解”，但基本上也都没什么实际效果。Hansson 引用了Magic Multi Connections，一个可以解决Twitter的问题的ActiveRecord插件，他评论说“Williams以代码来对Twitter可悲的伸缩性问题作了回复，当然我更愿意看到这解决方案是来自Twitter的，但不管怎样，很高兴他们有了一个免费的解决方案。”

作为回应，Blaine Cook，Twitter的另外一个开发者，告诉我们说他认为“Dr. Nic的解决方法做的很棒，同时加入了些不错的辅助方法来从数据库中选出连接。”，但应该注意的是，“Twitter现在并不是受数据库的限制，而且暂时也不会”。关于Twitter的伸缩性问题，Blaine指出“在访问最繁忙的时候，应该考虑应用程序的伸缩性，而不是框架本身。我之所以喜欢Rails，是因为它足够灵活，可以让我们把注意力集中在Twitter和用户身上。”

那么Twitter到底有多繁忙？稍作统计后，Blaine告诉我们说，现在Twitter每秒的连接数是600 个请求左右，而不是Hansson所说的11000个。虽然他们很有自信Twitter很快就会达到11000个的数量级。

争论仍在继续。Twitter开发团队仍在努力为他们糟糕的性能问题奋战着。Blaine将在这个周末在SDForum进行演讲，会谈到一些这方面的话题，当然这会成为会议的热点。但我们不要忘记，现在最大的网络应用之一，facebook.com有着17,000个请求/秒，这个数量是Twitter的30倍以上。

Magic Multi Connections插件的作者，Dr. Nic讲到“Twitter的人已经把他们的代码贡献给Ruby社区（Jabber API）, 并且当他们为自己的问题找到解决方案后，我想他们会非常高兴与我们分享的，很不错的迹象。记住：Rails只有2 年的历史，.NET + ISS有7年的历史，Java 有10年的历史。LAMP也有很长的历史了。所以，它们都跑在我们前面。Rails会带来更多的惊喜。”

查看英文原文：A Twitter in a Teapot?

译者简介：陈俊，SpringSide开源项目的核心成员，以及中科院软件工程硕士，就职于Accenture。长期从事Java EE应用开发,热衷于软件体系结构，设计模式，软件过程改进及敏捷开发研究，也喜欢尝试不同的开源技术，一直以来坚持为开源社区的发展贡献自己的力量。为InfoQ中文站贡献内容，请邮件至[email protected]。