BT

你的观点很重要! 快来参与InfoQ调研吧!

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

| 作者 James Cox 关注 0 他的粉丝 ,译者 陈俊 关注 0 他的粉丝 发布于 2007年4月24日. 估计阅读时间: 5 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

虽然已经过去了一个星期,社区里仍蔓延着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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

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

Scalability = “可伸缩性”?
“结合自动代理,绝大多数优秀的CNN和BBC种子会传给Twitter用户。” ?

要翻译就负责点好不好?

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

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

谁翻译的? by est Tu

谁翻译的?拖出去打啊

Ad hoc is a Latin phrase which means "for this purpose".

Twitter是一个ad-hoc(一种无线互连对等网络结构) 实时信息服务网站

@#¥%……&应该拖出去打!!!!!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT