Представление профилирования в Rails

Question

У меня большое представление, на завершение которого требуется очень много времени.Каков наилучший метод для профилирования, какая часть представления занимает больше всего времени?Я читал о ruby-prof, но я не уверен, куда его поместить, чтобы профилировать рендеринг вида.Если есть другие варианты, я тоже хочу их знать.

Answer 1

Самый простой способ быстро добраться до узких мест - использовать режим разработчика NewRelics, который работает локально.

1. Убедитесь, что в вашем Gemfile есть ruby-prof и newrelic_rpm.
2. Перейдите к localhost:3000/newrelic и начните профилирование (в правой панели)
3. Сделайте фактический запрос к странице вашего приложения, которую вы хотите профилировать, возможно, несколько раз, чтобы убедиться, что вы не измеряете некоторое кэширование и прочее.
4. Вернитесь в новый режим разработчика, выберите трассировку запроса.
5. Сортировка таблицы по столбцу "self". Это очень важно, поскольку сортировка по умолчанию по общему времени вводит в заблуждение.
6. Посмотрите на топ-10 вызовов, как они называются, и вы, вероятно, найдете узкое место.

Отказ от ответственности: я перевел эту функцию сортировки в режим разработчика newrelic, поэтому я предвзят. Однако попробуйте, если для себя.

Answer 2

Это довольно легко, на самом деле.Я только что нашел и исправил проблему производительности с шаблоном HAML, используя ruby-prof.Соответствующая часть шаблона выглядела примерно так:

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

Я убедился, что ruby-prof был в Gemfile, и временно изменил его на:

  - 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

Затем загрузите приложениенажмите на страницу пару раз и откройте недавно созданный profile.html в моем браузере, чтобы увидеть, какая часть вызывала проблему.

Answer 3

NewRelic и логи полезны, но иногда вам нужно больше. У NewRelic есть бесплатный инструмент, который поможет вам копать локально, а такие инструменты, как ruby-prof, предоставят вам информацию, но может быть трудно понять, что с этим делать.

Я наткнулся на страницу регистрации в клиентском приложении, которая была смехотворно медленной, без видимой причины. Журналы подтвердили, что это было медленно, и что медлительность не была связана с БД, но не помогла мне понять, в чем проблема.

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

Проще в использовании, чем ruby-prof, и его можно быстро включить / выключить, когда вам нужно погрузиться во что-то. Я использую его все время, помогая людям настраивать свои приложения на Rails. Это помогло мне понять, какая часть была медленной, и с небольшой пробой и ошибкой я обнаружил, что это был выпадающий список часовых поясов на странице регистрации

На одной странице это было (медленная версия): <% = time_zone_select: user,: time_zone, TZInfo :: Country.get ("US"). zone, {}%>

а другой был: <% = f.time_zone_select: time_zone, ActiveSupport :: TimeZone.us_zones,: default => "Тихоокеанское время (США и Канада)"%>

Мои номера до / после:

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

Я не копал дальше, поскольку мне нужно было решить другие проблемы, но было бы возможно кэшировать часовые пояса и получить еще более быстрый ответ.

Answer 4

Если вы этого не сделали, сначала проверьте папку log в папке приложения.Он содержит файлы журналов для каждой среды вашего приложения.

Чтобы профилировать приложение rails, поместите свои тесты в папку your_app/test/profile

http://ruby -prof.rubyforge.орг /