Будет ли XDebug на производственном сервере делать PHP медленнее?

Название в значительной степени говорит все это... это плохая идея? Я хотел бы иметь расширенные отладочные сообщения, которые XDebug предоставляет на сервере.

[править] Просто чтобы все было ясно. Я знаю, что есть риски безопасности. Возможно, я должен дополнить свой вопрос и дать более точные причины, по которым я хотел бы это сделать.

На нашем производственном сервере также размещена тестовая платформа. Иногда мы используем его для тестирования вещей в среде, максимально приближенной к производству. Главное, что я ищу, это использование расширенного XDebug var_dump().

Это не сервер приложений для приложений с высоким трафиком, и производительность не такая уж большая проблема. Мне было любопытно, будет ли производительность заметно влиять на XDebug.

Кроме того, я предполагаю, что могу включить его только для VirtualHost, который определяет сайты тестирования.

Ответ 1

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

Первый заключается в том, что когда вы добавляете поведение отладки на свой сервер, механизм отладки "присоединяется" к процессу PHP и получает сообщения от двигателя, чтобы остановиться на контрольных точках, и это BAD, потому что представляет собой высокоэффективный удар по иметь другой процесс, останавливающий или "сохраняющий" парсер PHP.

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

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

РЕДАКТИРОВАТЬ Как видно, мой ответ недостаточно документирован, вы должны проверить эти источники

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

Ответ 2

Замедление в 4 раз

Я сделал несколько тестов, позволяющих модулю без фактической отладки замедлять запрос на моей машине разработки с 1 секунды до около 4 секунд.

Ответ 3

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

Ответ 4

Вы никогда не должны держать это на производстве.

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

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

Скорость выполнения - это ваша наименьшая забота, в любом случае на нее будет влиять, как и память.

Ответ 5

Xdebug предназначен для добавления полных стековых трасс в журналы ошибок, то есть значение display_errors ini, которое, конечно же, должно быть выключено (даже в разработке я этого не хочу). Он не позволяет удаленное присоединение к отладчику, если вы не включили настройку remote_attach ini. Хотя это медленнее, если у вас есть тайная ошибка PHP, например, выделенная память Max или ошибка сегментации, это единственный способ увидеть, где она фактически была создана.

Ответ 6

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

Примечание. Очевидно, что это не относится ни к кому. Не каждый может легко клонировать сервер. Если вы используете облачные сервисы, такие как AWS и т.д., Это будет очень просто. Если вы используете инструменты настройки сервера, такие как Ansible, Chef, Puppet для создания своего сервера, это тоже кусок пирога.

Ответ 7

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

Ответ 8

Вы можете использовать XDebug в производстве, если вы "сделаете это правильно". Вы можете включить расширение в режиме "бездействия", который запускается только через запросы, которые проходят через определенное имя HOSTS. Подробности здесь:

http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug