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

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

Когда что-то загадочно ... профайлеры - ваш друг!

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

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

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

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

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

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

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

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

Я обнаружил, что большую часть времени рендеринга можно потратить на создание и подготовку объектов Active Record в Rails. После запроса и перед просмотром. Например, в зависимости от того, сколько записей возвращается в результате «находки».