Newrelic вызывает создание новых тегов для каждого запроса

Из-за того, что javascript вводится из-за newrelic, который изменяется при каждом запросе, содержимое страницы изменяется, что заставляет каждый раз генерировать новый etag.

Я понимаю, что промежуточное ПО Rack :: Etag должно быть раньше промежуточного ПО newrelic, но я просто не могу найти промежуточное ПО newrelic. Согласно документации newrelic_rpm, в нем говорится, что для rails гем будет включать промежуточное программное обеспечение, однако при запуске промежуточного программного обеспечения rake я не вижу никаких промежуточных программ newrelic.

Я могу сам добавить промежуточное ПО, но есть ли способ лучше?


person dhakadamit    schedule 26.08.2013    source источник


Ответы (2)


Я работаю в New Relic.

Причина, по которой промежуточное программное обеспечение New Relic не отображается при запуске rake middleware, заключается в том, что они условно вставлены в стек промежуточного программного обеспечения. Эти промежуточные программы вставляются только в том случае, если агент настроен для работы в текущей среде. Вы можете принудительно вставить промежуточное программное обеспечение New Relic при запуске rake middleware, чтобы проверить стек промежуточного программного обеспечения, установив NEW_RELIC_AGENT_ENABLED=true в командной строке при запуске задачи rake.

Добавление следующего кода в config/application.rb должно гарантировать, что промежуточное программное обеспечение Rack :: ETag имеет возможность вычислить и внедрить ETag до того, как промежуточное программное обеспечение мониторинга браузера внедрит свое динамическое содержимое:

 config.after_initialize do
      config.middleware.delete "Rack::ETag"
      config.middleware.insert_after "NewRelic::Rack::BrowserMonitoring", "Rack::ETag"
    end

Причина, по которой код JavaScript, вводимый в ответы NewRelic::Rack::BrowserMonitoring промежуточным программным обеспечением, является динамическим, заключается в том, что он содержит время, в течение которого ответ был сформирован на стороне сервера, и (если применимо), сколько времени он был поставлен в очередь до достижения стека Rails. Эти сроки будут меняться для каждого входящего запроса. Если ETag генерируются на основе хеширования содержимого страницы перед вставкой динамической информации, то при обслуживании ответа из кеша потенциально могут использоваться устаревшие серверные тайминги. Подробную информацию о том, как с этим справляется New Relic, можно прочитать здесь: https://newrelic.com/docs/features/how-does-real-user-monitoring-work#cached-pages

Это также хороший обзор правильного заказа промежуточного программного обеспечения: http://verboselogging.com/2010/01/20/proper-rack-middleware-ordering

Если вам нужна более подробная помощь, отправьте нам заявку по электронной почте [email protected].

person alice    schedule 27.08.2013
comment
Убедитесь, что для этого решения включен мониторинг браузера. - person Brian; 20.02.2014
comment
По какой-то причине это решение у меня не сработало. Я вынул строку config.middleware.insert_after и заметил, что строка удаления на самом деле не удаляла промежуточное ПО ETag, и даже после перемещения его из after_initialize строка insert_after не работала. Однако другое решение сработало отлично! - person jon_wu; 27.03.2014

Другой вариант:

  1. Установите browser_monitoring.auto_instrument: false в файле newrelic.yml, чтобы отключить автоматическую вставку промежуточного программного обеспечения BrowserMonitoring.
  2. Добавьте следующий код в config / application.rb:

    config.middleware.delete "Rack::ETag"

    require 'new_relic/rack/browser_monitoring'

    config.middleware.use NewRelic::Rack::BrowserMonitoring

    config.middleware.use "Rack::ETag"

Это удалит промежуточное программное обеспечение ETag, добавит промежуточное программное обеспечение BrowserMonitoring, а затем снова добавит промежуточное программное обеспечение ETag, чтобы оно запускалось до того, как BrowserMonitoring внедрит свою динамическую полезную нагрузку.

person lauradiane    schedule 02.01.2014