虽然已经过去了一个星期，社区里仍蔓延着 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 中文站贡献内容，请邮件至 china-editorial@infoq.com 。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论