Rails 3.2 性能： 更慢了？

拥有一个大型代码库意味着我们不能很经常升级Rails的版本（我们平均每两年一次升级，每次升级需要1-2周的开发时间）。不过每次我们做升级工作的时候，我最先好奇的事情之一是，检查不同版本之间的性能差异。 就我们之前的升级来说，在从Rails 2.3 到 Rails 3.0的过程中，我记录下来的平均动作变得要慢2倍，一个动作需要的平均时间由225ms攀升到480ms。幸运的是，在这种情境下我们可以拿出一些技巧（GC调优），这样我们最终将同样的动作时间缩减到280ms。即使是实现一些新奇的技巧，这个时间仍然比Rails 2.3要慢约25%，但是我们已经可以接受这个结果了。

当我们最终决定由Rails 3.0升级到3.2，以便与最新的gems兼容的时候，由于我们之前的经历，可想而知我对性能有何等下降是多么的急切。根据手头现有数字，看来有必要对此加以理解。这里是上次我描述到的同一个动作（最常见的动作——显示一个条目的动作）的不同表现情况，在升级以前的Rails 3.0上： 在升级以前最常见的动作，在3小时的时间窗口中平均需要301ms 这里是现在的样子： 升级以后，与上周相同时间段，在3小时的时间窗口中平均需要423ms

与上次不同，3.2的问题在于，我们再也没有办法凭空捏造更多的技巧。我们已经升级到最新最伟大的Ruby 2.0版本。在请求期间我们已经禁止了GC（感谢有Passenger！）。我们完成这些升级以后，Rails 3.0的应用速度快了大约25%。但是现在由于Rails 3.2中我们需要承受控制器与视图渲染的40%性能下降，这些性能提升被遮蔽了，而且在做Ruby优化以前，反而比3.0中的速度还要慢。 总而言之，如果你有基于Rails的大型应用，此刻你可能已经懂得对Rails新版本心存畏惧。我完全理解那些为 Rails LTS交钱的人。（译注：LTS即 Long Term Support）如果我们不需要与新的gems兼容，仍然使用2.3，这将使我们比Rails 3.0速度快100%，相应的比Rails 3.2速度快40%。

新版的Rails 鼓吹各种改进，像“创建单页web应用的能力”、“更严格的默认安全性”以及“改革，简化”其组成库。我们看到的最近一次的性能提升，是3.2版本使开发环境的加载加快了(1)。这显然是一个令人难以置信的提升（使平均的开发页加载由5秒以上缩减到1-2秒），尽管由于active_reload，我们已经在Rails 3.0有这样的性能提升。 我觉得在驱动Rails开发的各种要素中，现在性能已经成为最不被关注的一个了，如果真是如此，那么这是令人相当羞愧的。如果Rails也像它所做的“改革，简化”一样，花同等的时间分析/改进性能，很难相信每次版本升级我们会承受40%-100%的性能退化。或许与New Relic的合作可以帮助Rails团队看到，对那些基于他们的平台而创建的实际应用来说，他们的决策具有何种现实的影响。如果其他人的经历与我们相似，那么可以说这是许多人感受到的许多的痛苦。

我承认我有点不愿意写这篇文章，因为作为一个平台Rails给了我们太多，而且目前我们的业务太小，还不至于能直接牵涉到Rails的性能改进。但是我们将继续发表任何我们发现的、明显的优化策略，发表到这个博客或者别的什么地方。 不过我最关心的，同时也是我发表此文的原因是，如果Rails继续以这样的幅度降低速度，我不确定是否在4.x 或 5.x系列版本中，是否会有“没有返回的时间点”，在那时它将慢到我们无法再做任何升级。每次我们追随的新版本都向着那种可能性迈进了一步，即使我们购买了史上最快的服务器，并且给编译器实现了史上最耗心血的优化。

还有人做过由中等规模到大规模webapp的Rails 2 -> 3 -> 4这样的升级吗？我非常渴望听到你的经验。当Google搜索“Rails性能”时，只有很少的一点结果，这总是使我想知道其他开发者升级经验的更多细节。 (1)就像在兼容的web服务器上使用动态流一样，在某些情况下，新的缓存模型也可以提升性能。由于这篇文章的目的我是着眼于“性能”，而性能属于在服务器上运行的动态web应用程序范畴，这意味着（我们所关注的是）诸如解释请求，与数据库交互，以及呈现响应。