在New Relic上，对Heroku Rails应用程序的“花在Ruby中的时间”有何贡献？

我正在尝试改善Heroku上托管的beta版Rails 3.2应用程序的性能。

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

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

最初，我认为这是由于我的一个主控制器中的条件复杂，但已对此进行了简化。现在，使用Russian Doll片段缓存和memcache可以非常积极地缓存我的视图（哇！）。

可以动用静态资产吗？（移至S3 / CloudFont在待办事项列表上...）

谢谢！

（我已经设置了delay_job设置，并将所有可能的操作移到了后台。我也正在使用Unicorn作为我的Web服务器。）

更新的性能调整

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

首先，我根据建议添加了垃圾回收监控，发现GC对Ruby时间的贡献不大。

接下来，我决定通过添加CDN（通过CDNsumo插件在Cloudfront中）来实现我的资产服务。有趣的是，这确实减少了我在NR监视上的Ruby时间。（已预配置CDN，然后通过下图最右边的最后一个请求测试进行预热。）我的大多数页面都有数百kb的CSS和javascript-很小但不是很大。

Finally, I upgraded from the 'Basic' starter database to the smallest production db 'Crane'. This had a dramatic effect on performance. After a little caching by PG the app flies. (final 3 request spikes on the graph below).

Take home messages for others trying to tune their Heroku apps:

• Simple performance tuning in multiple areas (ie. caching, CDN, database, Ruby code) has a synergistic effect across the stack.
• Conversely, any single performance drain will be a bottleneck that you cannot overcome even if you tune the other areas (ie. the slow starter Basic or Dev databases on Heroku versus an 'expensive' production database - the slow Basic db was killing my app performance).
• NewRelic is essential in working out where the most gains can be made.