5

I am trying to improve the performance of my pre-beta Rails 3.2 app hosted on Heroku.

Aggressive caching has dramatically improved things, but I still notice a large contribution from "Time spent in Ruby" when looking at my app server response time on New Relic (light blue on the graph).

What parts of a Rails app typically contribute to this 'Ruby time'?

New Relic time spent in ruby

I initially thought this was due to complex conditionals in one of my main controllers, but have simplified this. My views are now very aggressively cached using Russian Doll fragment caching and memcache (wow!).

Could serving of static assets be a cause? (Moving to S3 / CloudFont is on the todo list...)

Thanks!

(I already have delayed_job setup and have moved all that I can into the background. I'm also using Unicorn as my web server.)

UPDATED Performance Tuning

After aggressive caching, I started looking for other ways to improve app performance.

First I added Garbage Collection monitoring as suggesting, finding that GC was not significantly contributing to the Ruby time.

enter image description here

Next I decided to hit my asset serving by adding in a CDN (Cloudfront via the CDNsumo add-on). Interesingly this did actually decrease my Ruby time on NR monitoring. (The CDN was provisioned and then warmed by the last request-test on the far right of the graph below.) Most of my pages have a couple-hundred kb of css & javascript - so not tiny but not massive.

enter image description here

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).

enter image description here

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.
4

1 回答 1

7

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

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

GC::Profiler.enable

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

如果您的 GC 状况良好，下一步是使用 Web 事务视图查看这些平均时间是如何分布的。也许您的应用程序中的一两个操作表现得很糟糕，并且对这些平均值负责。

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

于 2013-09-21T15:57:32.357 回答