InfoQ

新闻

是Twitter不努力,还是Rails本身有问题?

作者 James Cox译者 陈俊 发布于 2007年4月24日 上午8时6分

社区
Ruby
主题
开放源代码,
性能和可伸缩性,
社区,
Ruby on Rails
标签
Rails,
负载均衡,
Web 2.0,
ActiveRecord,
LAMP,
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中文站贡献内容,请邮件至china-editorial@infoq.com

3 条回复

回复

这篇文章不是机器自动翻译的吧? 发表人 Bruce Wang 发表于 2007年4月27日 下午1时35分
Re: 这篇文章不是机器自动翻译的吧? 发表人 chen jun 发表于 2007年4月29日 上午6时34分
谁翻译的? 发表人 est Tu 发表于 2008年4月15日 下午2时8分
  1. 返回顶部

    这篇文章不是机器自动翻译的吧?

    2007年4月27日 下午1时35分 发表人 Bruce Wang

    Scalability = “可伸缩性”? “结合自动代理,绝大多数优秀的CNN和BBC种子会传给Twitter用户。” ? 要翻译就负责点好不好?

  2. 返回顶部

    Re: 这篇文章不是机器自动翻译的吧?

    2007年4月29日 上午6时34分 发表人 chen jun

    Scalability 在这里的确应该翻译成“可伸缩性”或“可扩缩性”,原文中理解的意思是在一个应用可以容纳不同数量级的访问。 “结合自动代理,绝大多数优秀的CNN和BBC种子会传给Twitter用户。” 这句是意译而已,不知兄台对这句翻译有何高见?

  3. 返回顶部

    谁翻译的?

    2008年4月15日 下午2时8分 发表人 est Tu

    谁翻译的?拖出去打啊 Ad hoc is a Latin phrase which means "for this purpose". Twitter是一个ad-hoc(一种无线互连对等网络结构) 实时信息服务网站 @#¥%……&应该拖出去打!!!!!

独家内容

Tapestry for Nonbelievers

I. Drobiazko和R. Zubairov合作撰写了一篇文章,详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法,并谈到了Tapestry中的IoC以及Ajax的相关特性。

ESB拓扑方案

在本文中,Adrien Louis讨论了两种基于ESB的SOA拓扑方案的优缺点:单个公司级ESB vs. 彼此互联的“部门级”ESB系统。Adrien讨论了每种方案对管理、业务监测、治理、可靠性和编配等问题的影响。

毛新生谈Project Zero和软件新发展

InfoQ中文站有幸与IBM中国开发中心Web 2.0首席架构师毛新生聊了聊Project Zero和软件新发展的相关话题,其中包括Project Zero的组织形式、支持的语言、以及未来发展方向等等。

Google图表及gchartrb初探

Google图表是一项用于生成图表的Web服务。这篇文章详细介绍了Google图表的接口以及可以允许Ruby方便创建图表的gchartrb库。

使用Erlang和Yaws开发REST式的服务

在这篇文章中,Steve Vinoski解释了如何用Erlang和Yaws Web服务器创建REST式Web服务。

Segundo Velasquez与客户眼中的敏捷

在某个软件产品设计的初始阶段,Segundo Velasquez曾以客户的身份与一个敏捷团队共同工作;Deborah Hartmann就这段经历对他进行了采访。

开放平台技术架构剖析

本视频从互联网的分类讲起,介绍了开放平台的类型、开放的价值以及开放平台对开发者的机会和挑战。然后以雅虎的NCP开放平台为例,讲解了NCP的特点、基本架构和具体的开发过程。

用UML做好系统分析

使用UML如何能让我们做好系统分析的工作呢?就让我们通过基金模拟项目,先睹为快,抢先体验一番。 本文节选自《系统分析师UML实务手册》的第二章。