Почему время рендеринга моего сервера Rails не увеличивается?

Question

У меня проблемы с тем, что мое Rails-приложение работает очень медленно на моем промежуточном сервере. Что больше всего сбивает с толку, так это то, что последняя строка журнала выводит для каждого запроса.

Похоже, что время просмотра и базы данных даже не близко ко всему времени рендеринга. На одной странице это плохо: ~ 1000 мс для завершения, ~ 450 мс для просмотра и ~ 20 мс для базы данных.

Откуда берется остальное время, необходимое для отображения страницы?

Answer 1

Я обнаружил, что большая часть времени рендеринга может быть потрачена на Rails при создании и подготовке объектов Active Record. После запроса и до просмотра. В зависимости от того, сколько записей возвращено из 'find', например.

Answer 2

Когда все загадочно .... Профилировщики - ваш друг!

Профилировщик будет составлять статистику того, какие методы вызываются чаще всего и сколько времени тратится на каждый вызов метода.

ruby-prof помогает мне, когда я нахожусь в RubyLand, и создает хороший колл-граф (в формате html, если хотите), который делает его красивым и легко видимым какие методы замедляют ваш запрос.

Answer 3

Что говорит ваш журнал apache? Он определенно будет иметь разные номера, чтобы показать время, необходимое для обработки запроса.

Apache отправляет запросы на рельсы, и рельсы работают над ним, и это то, что вы видите в своих производственных журналах.

Весь HTML все еще должен отображаться в вашем браузере (тяжелый CSS, изображения, js и т. Д.). Попробуйте использовать расширение httpwatch для Firefox, чтобы узнать время рендеринга элементов пользовательского интерфейса, и оно должно сложиться.

Как предлагалось ранее, NewRelic должен дать вам приличное распределение времени, потраченного на различные виды деятельности (M V C)

Answer 4

Помимо времени рендеринга и базы данных, некоторое время тратится на код контроллера и инфраструктуру Rails. Это может быть очень медленным, если вашему промежуточному серверу назначено слишком мало ресурсов. Однако не следует указывать, что длительности в журнале не всегда идеальны, особенно длительность базы данных.

Answer 5

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

Answer 6

Я рекомендую использовать RPM-сервис New Relic . У него есть бесплатная версия, но сервис Bronze (40 долларов в месяц) замечательный и помогает отслеживать эти проблемы.