【发布时间】:2011-03-31 16:30:36
【问题描述】:
Ruby on Rails 站点通常比 java 或 .net 站点慢吗? (这是假设开发人员没有滥用该技术。)
我见过的很多 Ruby 网站都存在性能问题。
【问题讨论】:
标签: ruby-on-rails ruby performance
Ruby on Rails 站点通常比 java 或 .net 站点慢吗? (这是假设开发人员没有滥用该技术。)
我见过的很多 Ruby 网站都存在性能问题。
【问题讨论】:
标签: ruby-on-rails ruby performance
是的,Ruby on Rails 网站确实存在性能问题,就像任何其他网站一样。就像任何其他网站一样,这些性能几乎总是植根于架构决策,而不是语言或框架。
几年前,Joyent 做了一个很好的演示(可能是 RailsConf 2007?),在一张幻灯片上展示了在其 Rails 平台的单个实例上运行的所有服务器。大约40个过程。这些进程中只有一个是 Ruby 解释器,其他一切都是 DNS 解析器、Web 服务器、数据库服务器、MTA、memcached、消息队列、反向代理、负载平衡器等。每一个都可能会破坏你的性能.你的性能问题有 97.5% 的可能性与 Rails 或 Ruby 无关。
JRuby 邮件列表上有一些非常棒的电子邮件,还有一些用 Ruby 重写 Java Web 应用程序并获得 10% 性能提升的人的推文和博客文章。
推特就是一个很好的例子。 Twitter 是世界上最大的 Ruby on Rails 网站之一。它也是一个非常不寻常的使用模式,这将使任何为“普通”Web 应用程序设计的框架难以破解。
现在,您可能会想,为什么我选择 Twitter 作为性能和可扩展性的一个例子,而显然它们正是众所周知的相反为了?嗯,这正是重点:他们遇到了吨 的扩展、性能和可靠性问题。其中一个与 Rails 或 Ruby 没有任何关系。事实上,Rails 和 Ruby 几乎是他们堆栈中唯一没有有问题的部分。
他们遇到了意外增长的问题。您使用哪种语言或框架无关紧要:如果用户登录的速度快于您购买新服务器的速度,那么您无能为力。
他们在 MySQL 的性能和可扩展性方面存在问题。同样,MySQL 与 Rails 或 Ruby 无关。事实上,MySQL 是用 C 语言编写的,所以如果你真的绝对必须仅仅根据一个事件对编程语言做出任何荒谬的结论,那么就是这样: C 很慢。如果您想要性能,请远离 C。
(在这种特殊情况下,在一次采访中,他们确实责备 Rails:他们说因为 Rails 只支持到单个数据库的单个连接,所以他们的 MySQL 实例简单地过载了。在几个小时内在发布的那次采访中,两位相互独立的 Rails 开发人员都发布了 Rails 插件来实现多个连接。教训是:只有 80% 的解决方案在核心。Twitter 显然不在 80%。插件 API 是是有原因的。)
他们在整个系统的性能和可扩展性方面存在问题。事实证明,为了快速推出产品,他们完全没有实施任何缓存。甚至“静态”的 Twitter 主页也是为每个请求完全动态生成的。同样,这与 Rails 或 Ruby 无关。您可以通过关闭缓存来关闭任何网站,我向您保证。
他们遇到了一些非常糟糕的可扩展性问题(上面提到的 MySQL 问题与此有关),这仅仅是由于人们以开发人员未预料到的方式使用该站点这一事实造成的。大家都知道推特是一个微信平台。好吧,除了 Twitter 的创始人。他们想出了一个关于微内容管理系统的绝妙主意。
因此,他们确实构建了一个微型 CMS。当然,内容管理系统的核心部分是内容存储库,IOW 是数据库。然而,用户将 Twitter 用作微消息平台。消息平台的核心部分是消息队列。
因此,MySQL 被用作消息队列。没有比数据库(尤其是 SQL 数据库)和消息队列更远的两件事了。两者的要求和约束几乎完全相反。
当然,整个架构是围绕现在被滥用为消息队列的内容存储库构建的。
为此,Twitter 开发人员用 Ruby 编写了自己的消息队列,这极大地提高了性能和可扩展性。但还不够。因此,他们编写了另一个消息队列,这次是在 Scala 中。
我估计,正是这种单一的重写完全负责了至少 70% 的 Rails FUD。但是,我不了解你:当我写一些我完全不知道该怎么写的东西,然后我第二次写完全相同的东西时,我实际上确实知道什么哎呀我在做什么......第二个总是比第一个好。我怀疑这里也是这种情况。
在几次采访中,Twitter 开发人员指出 Ruby on Rails 不应对他们的扩展问题负责。相反,只有 Ruby 的可维护性才能进行如此大规模的架构更改以修复它们的扩展问题。
长话短说:今天,Twitter 实际上正在将 Ruby on Rails 用于其预期用途:用于 Web 应用程序。他们使用数据库来存储数据,而不是作为消息队列。他们使用实际正确的消息队列。消息队列和其他一些后端东西是用 Scala 编写的。前端是用 Ruby on Rails 编写的。有些东西是用 C 写的。
一切都很美好。
这里故事的真正寓意是,您可以将几乎任何大型网络应用程序、任何语言、任何框架替换为上述故事,它仍然是真的。 MySpace 是我所知道的最慢、最不可靠的网站之一,它是一个 .NET 网站。 GitHub 是我所知道的最快的网站之一,同时也是最大的托管平台(在短短 2 年多的时间里,它拥有超过一百万个存储库,这比 SourceForge 和 Google Code 的总和还多),它是用 Ruby on Rails 编写的前端, Sinatra 用于 Web 服务,Ruby 用于 Git 接口和 Git 基础架构,Erlang 用于联邦和云基础架构,Node.JS 用于下载服务器。
【讨论】:
这是一个开始
Framework Preformance Comparison
Related interest article Twitter abandons ROR its old I know but I didnt actually know that lol
简答
可能确定。
可能比其他一些语言更有可能。
取决于应用程序、程序员和架构。
【讨论】:
在我看来 - RoR 只是慢了一点。至少比 .Net 慢,因为 ruby 是解释性语言。
但总的来说 - 这取决于开发人员的素质。使用良好缓存的 RoR 应用程序将比 .net/java 应用程序快 n 倍,后者将一半数据库加载到内存中并发送大量数据库请求,原因是 select n+1。
【讨论】:
是的,它速度较慢,但在生产中,它可能只会在您的负载“超过某个点”(“x 个请求/秒”)时才会对您造成伤害,并且大多数网站从来没有看到比这更多的负载。
【讨论】: