Как отключить профилировщик в Symfony2 в производстве?

Я не имею в виду панель инструментов - я имею в виду профайлер.

Я хочу отключить его в процессе производства, я использую его для разработки, поэтому решение с удалением его пакета - это не-go.

Я попытался установить framework.profiler.only_exceptions на true. Я попытался удалить раздел framework.profiler вообще. Независимо от того, что profiler.db растет после каждого запроса, и каждый ответ содержит заголовок x-debug-token.

Я дважды проверял файлы конфигурации (config.yml и config_prod.yml), и все кажется оштрафованным.

Чем больше команда app/console router:dump-apache --no-debug всегда выгружает маршруты _wdt и _profiler, но у меня их нет в моем routing_prod.yml, и они, похоже, не присутствуют при попытке получить к ним доступ из браузера (404).

Я запускаю symfony 2.0, и сейчас я не буду обновлять его из-за некоторых серьезных изменений в 2.1, которые потребуют перезаписи многих элементов. Было бы неразумно запускать его непосредственно перед первоначальным развертыванием.

Ответы

Ответ 1

Symfony >= 2.2

Как и в Symfony 2.2, профилировщик поддерживает флаг enabled в конфигурации структуры и по умолчанию отключен в среде test.

# app/config/config_test.yml
framework:
    profiler:
        enabled: false

Смотрите Запись в блоге о профилировании от Fabien Potencier и Ссылка на конфигурацию FrameworkBundle для более подробной информации.

Обновление: этот флаг по-прежнему действует в Symfony 4.0.

Symfony <= 2.1

В Symfony <= 2.1 Профилировщик полностью отключен, если в конфигурации нет framework.profiler.

Вы можете увидеть это в ProfilerPass конфигурации Symfony2 FrameworkBundle.

Это относится к умолчанию config.yml и config_prod.yml (который включает в себя первый). Поэтому, если вы не переделываете настройки по умолчанию, вы в порядке.

В config_dev.yml однако значение по умолчанию:

framework:
    profiler: { only_exceptions: false }

Что позволяет профилировать среду dev и все среды, которые импортируют config_dev.yml, как config_test.yml.

Если вы хотите отключить значение профилировщика в следующей конфигурации, используйте:

framework:
    profiler: false

Значения типа {} или ~ не будут отменять значение. Вы должны использовать false.

Ответ 2

Вы попробовали это (включите только для разработки)

Поскольку профилировщик добавляет некоторые накладные расходы, вы можете включить его только при определенных обстоятельствах в производственной среде. настройки только-исключения ограничивают профилирование до 500 страниц, но что, если вы хотите получить информацию, когда клиентский IP-адрес поступает из определенного адрес или для ограниченной части веб-сайта? Вы можете использовать запрос:

framework:
    profiler:
        matcher: { ip: 192.168.0.0/24 }

http://symfony.com/doc/current/book/internals.html#profiler

или

профайлер можно отключить на основе действия, выполнив что-то вроде:

if(in_array($this->container->get('kernel')->getEnvironment(), array('prod'))) {
    $this->container->get('profiler')->disable();
}

Ответ 3

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

Во-первых, я рассмотрел Configuration в файле FrameworkBundle и выяснил, что в профилировщике conf node есть canBeDisabled(). Затем я проверил, что это означает точно.

Оказывается, каждый canBeDisabled node имеет подразумеваемый дочерний node enabled со значением по умолчанию, установленным на true. Вы можете либо переопределить его, либо установить родительский node непосредственно на false или null, чтобы отключить этот раздел. Если вы просто опустите раздел профилировщика, то он по умолчанию включен.

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

Кстати, я заметил, что когда profiler.db растет, каждый запрос становится медленнее, но это может быть не так в prod.