在 New Relic 上，Heroku Rails 应用程序的“使用 Ruby 的时间”有什么影响？

Question

我正在尝试提高我在 Heroku 上托管的预测试版 Rails 3.2 应用的性能。

积极的缓存已经显着改善了一些事情，但是当我在 New Relic 上查看我的应用服务器响应时间时，我仍然注意到“在 Ruby 中花费的时间”做出了很大贡献（图表上的浅蓝色）。

Rails 应用程序的哪些部分通常会促成这个“Ruby 时间”？

我最初认为这是由于我的一个主控制器中的复杂条件造成的，但已经简化了这一点。我的视图现在使用俄罗斯娃娃片段缓存和内存缓存非常积极地缓存（哇！）。

提供静态资产会是一个原因吗？ （迁移到 S3 / CloudFont 已在待办事项列表中......）

谢谢！

（我已经设置了delayed_job，并将所有我能做的都移到了后台。我还使用Unicorn 作为我的网络服务器。）

更新的性能调整

在积极缓存之后，我开始寻找其他方法来提高应用性能。

首先我建议添加垃圾收集监控，发现 GC 对 Ruby 时间没有显着贡献。

接下来，我决定通过添加 CDN（Cloudfront 通过 CDNsumo 插件）来提供资产服务。有趣的是，这确实减少了我在 NR 监控上的 Ruby 时间。 （CDN 是由下图最右侧的最后一个请求测试提供的，然后被加热。）我的大多数页面都有几百 kb 的 css 和 javascript - 所以不是很小但不是很大。

最后，我从“Basic”入门数据库升级到最小​​的生产数据库“Crane”。这对性能产生了戏剧性的影响。经过 PG 的一点缓存后，应用程序飞起来了。 （下图中的最后 3 个请求峰值）。

为尝试调整 Heroku 应用程序的其他人带回家消息：

• 在多个领域（即缓存、CDN、数据库、Ruby 代码）进行简单的性能调整可以在整个堆栈中产生协同效应。
• 相反，任何单一的性能消耗都将成为您无法克服的瓶颈，即使您调整其他区域（即 Heroku 上的慢速启动 Basic 或 Dev 数据库与“昂贵”的生产数据库 - 慢速 Basic db 正在扼杀我的应用性能）。
• NewRelic 是确定在哪里可以获得最大收益的关键。

Answer 1

“Ruby”时间实际上是 NewRelic 追踪的“Other”桶。其他类别是显式度量（即：调用 memcached 花费了多少时间）。 Ruby 时间是所有时间都没有花在其中一个桶中。

那么在“Ruby”时代还会发生什么其他事情？排名第一的候选人是垃圾收集（GC）。如果你运行的是 Ruby 1.9+，你可以通过创建一个像 config/initializers/newrelic.rb 这样的初始化器来启用 GC 的 NewRelic 分析：

GC::Profiler.enable

这会将 GC 时间作为一个单独的 NewRelic 类别为您跟踪。

如果您的 GC 状况良好，下一步是使用 Web 事务视图查看这些平均时间是如何分布的。也许您的应用程序中的一两个操作表现不佳，并导致这些平均值。

祝您好运，如果您仍有问题，请随时直接与我们联系。性能调优是一门黑色艺术。