Улучшение производительности приложения rails 3: лучший рабочий процесс? - PullRequest
2 голосов
/ 21 октября 2011

Я хочу улучшить производительность своего приложения и начал читать http://guides.rubyonrails.org/performance_testing.html. Мои вопросы в конце этого выступления "Как я начал".

Итак, я начал просто с

class BrowsingTest < ActionDispatch::PerformanceTest
  self.profile_options = { :runs => 5, :metrics => [:wall_time, :process_time],
                       :output => 'tmp/performance', :formats => [:flat] }
  def test_homepage
    get '/'
  end
end

вывод

bundle exec rake test:profile

в терминале равен

BrowsingTest#test_homepage (909 ms warmup)
           wall_time: 341 ms
        process_time: 517 ms

, а в плоском файле process_time он начинается так:

Thread ID: 70299857145540
Total: 2.589931

 %self     total     self     wait    child    calls  name
 12.45      0.32     0.32     0.00     0.00      110  BasicObject#method_missing
 10.59      0.28     0.27     0.00     0.01      415  Kernel#raise
  7.79      0.20     0.20     0.00     0.00     1350  <Class::Dir>#[]

Не зная, что с этим делать, я начал с поиска того, что часто использует method_missing.Я обнаружил, что библиотека, которую я использую для преобразования метрик (Alchemist), делает это и включает себя в класс Numeric.

Поскольку домашней странице это не нужно, я просто удалил библиотеку и перезапустилтест профилирования.На этот раз я получил следующее

BrowsingTest#test_homepage (856 ms warmup)
           wall_time: 321 ms
        process_time: 482 ms

И у плоского файла больше не было method_missing

Thread ID: 70185893711560
Total: 2.420023

 %self     total     self     wait    child    calls  name
 12.05      0.29     0.29     0.00     0.00        5  ActionView::Base#helpers
  8.32      0.20     0.20     0.00     0.00     1350  <Class::Dir>#[]
  5.12      0.12     0.12     0.00     0.00     5925  String#gsub

Я запустил его во второй раз и получил

BrowsingTest#test_homepage (856 ms warmup)
           wall_time: 321 ms
        process_time: 482 ms

Thread ID: 70231460630220
Total: 2.411142

 %self     total     self     wait    child    calls  name
 14.18      1.49     0.34     0.00     1.16     3265  Array#each
  8.26      0.20     0.20     0.00     0.00     1350  <Class::Dir>#[]
  4.94      0.12     0.12     0.00     0.00      205  Kernel#caller

Таким образом, кажется, что не использование библиотеки экономит ~ 35 мс времени процесса, что, по-видимому, вполне согласуется с тем, что говорят плоские файлы.Думаю, мне следует попытаться что-то с этим сделать, тем более что он, кажется, вызывается так часто из-за числового включения.

Теперь вот мои вопросы:

  • Этоправильный подход?Есть ли лучший способ начать?
  • Какой лучший способ определить класс / метод, который снижает производительность (следующий шаг для меня - поиск чего-то с помощью Dir, но есть несколько мест, где он используется)
  • Какое допустимое время процесса?
  • Я запустил тест: профиль несколько раз подряд, а время для "String # gsub" изменилось с 0,04 до 0,12.Что может случиться?

Спасибо!

Ответы [ 2 ]

1 голос
/ 15 декабря 2011

Мне нравится, как вы познакомились с инструментами и как читать результаты. New Relic - отличный инструмент для мониторинга этого материала, но также и request_log_analyzer, если вы не хотите платить за новую реликвию в течение длительного времени.

  1. используйте Yslow или Page speed для профилирования вашей полной страницы, а не только загрузки html
  2. Оптимизация страницы, как она загружает / кэширует ресурсы
  3. Найдите ваши самые медленные действия и выясните, что они делают (медленный код или медленный запрос?)
  4. Оптимизация запросов, добавление индексов, где это необходимо, кеширование данных
  5. Удалить или обновить старые библиотеки
  6. автономные дорогостоящие процессы (фоновые, cron-задания и т. Д.)
  7. Настройте вашу архитектуру (вам не нужны Rails для всего, запрыгивайте на jruby и используйте мощные библиотеки Java, многопоточность и время выполнения)

Мониторинг важен, поэтому вы знаете, когда возникает проблема

-Джон МакКаффри

1 голос
/ 20 ноября 2011

Я действительно не чувствую, что эти тесты производительности страницы необходимы. Я считаю важным только раннее развертывание и включение некоторой формы мониторинга приложений (например, новых реликтовых RPM). Через него вы можете определить все узкие места вашего приложения и со временем исправлять их по мере роста приложения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...