Profiling view in Rails

I开发者_StackOverflow中文版 have a big view, which takes very long to finish to render the content. How is the best method to profile, which part of the view is taking the most time ? I have read about ruby-prof, but I'm not sure, where to put in it, to profile the view rendering. If other options exists, I want to know them too.

The easiest way to quickly get to bottleneck is using NewRelics Developer mode which works locally.

1. Make sure you have ruby-prof and newrelic_rpm in your Gemfile.
2. Navigate to localhost:3000/newrelic and start profiling (in the right bar)
3. Make an actual request to page of your app you want to profile, possibly multiple times to make sure you don't measure some caching & stuff.
4. Navigate back to newrelic developer mode, pick request trace.
5. Sort the table by "self" column. This is crucial since the default sorting by total time is misleading.
6. Look on top-10 calls, how are they called and you probably find the bottleneck.

Disclaimer: I've pushed this sorting feature to newrelic's developer mode, so I am biased. However try if for yourself.

It's pretty easy, actually. I just found and fixed a performance problem with a HAML template using ruby-prof. The relevant part of the template looked something like:

  - @collection.each do |x|
    = render :partial => 'name', :locals => {:object => x}

I made sure ruby-prof was in the Gemfile and temporarily changed that to:

  - require 'ruby-prof'
  - RubyProf.start
  - @collection.each do |x|
    = render :partial => 'name', :locals => {:object => x}
  - result = RubyProf.stop
  - printer = RubyProf::CallStackPrinter.new(result)
  - file = File.open('profile.html', 'w')
  - printer.print(file)
  - file.close

Then boot up the app, hit the page a couple times, and open up the newly created profile.html in my browser to see which part was causing the problem.

NewRelic and the logs are helpful, but sometimes you need more. NewRelic does have a free tool that can help you dig locally, and tools like ruby-prof will give you info, but it can be hard to know what to do with it.

I came across a sign up page in a client's app what was ridiculously slow, for no apparent reason. The logs confirmed that it was slow, and that the slowness was not due to the db, but didn't help me see what the issue was.

https://github.com/brynary/rack-bug/

Is easier to use than ruby-prof, and can be turned on/off quickly when you need to dive into something. I use it all the time when helping people tune their Rails apps. It helped me understand which partial was slow, and with a little trial and error, I discovered it was the drop down for timezones on the sign up page

On one page it was (the slow version): <%= time_zone_select :user, :time_zone, TZInfo::Country.get("US").zones, {} %>

and another was: <%= f.time_zone_select :time_zone, ActiveSupport::TimeZone.us_zones, :default => "Pacific Time (US & Canada)" %>

My before/after numbers:

orig template render          1392.91
fixed template render         165.56
fixed on REE instead of 1.8.7 100.70

I didn't dig any further, as I had other issues to fix, but it would be possible to cache the timezones and get an even faster response.

If you did not do it, check folder log in application folder first. It contains log files for every environment of your app.

In order to profile a rails app, put your tests to folder your_app/test/profile

http://ruby-prof.rubyforge.org/