Название в значительной степени говорит все это … это плохая идея? Я хотел бы иметь расширенные отладочные сообщения, которые XDebug предоставляет на сервере.
[править] Просто, чтобы все было ясно. Я знаю, что есть риски безопасности. Возможно, я должен дополнить свой вопрос и дать более точные причины, по которым я хотел бы это сделать.
На нашем производственном сервере также находится платформа тестирования. Иногда мы используем его для тестирования вещей в среде, максимально приближенной к производству. Главное, что я ищу, это использовать расширенный var_dump() XDebug.
Это не сервер приложений для приложений с высоким трафиком, и производительность не такая уж большая проблема. Мне было просто любопытно, что XDebug заметно повлияет на производительность.
Кроме того, я предполагаю, что могу включить его только для VirtualHost, который определяет сайты тестирования.
Помимо очевидного факта, что отладочные сообщения не могут быть отображены в приложении, которое уже находится в процессе производства, а также о том, что я не знаю, почему вам это нравится, есть пара вещей, которые действительно плохо об этом.
Первый заключается в том, что когда вы добавляете поведение отладки на свой сервер, отладочный движок «присоединяется» к процессу PHP и получает сообщения от двигателя, чтобы остановиться на контрольных точках, и это BAD, потому что представляет собой высокоэффективный удар, чтобы иметь другой процесс остановка или «сохранение» парсера PHP.
Еще одна большая проблема заключается в том, что, когда установлен отладчик, по крайней мере, большинство из них, они склонны иметь неприятную привычку открывать порты на вашем сервере, поскольку они не предназначены для производственных сред и, как вы знаете, любое программное обеспечение, которое открывается порты на вашем сервере открывают дверь для любого хакера.
Если вам нужно отлаживать ваш код, то в вашем приложении внедрить систему отладки, если она недоступна, так как большинство фреймворков имеют эту встроенную систему. Задайте значение конфигурации, например DEBUG_ENABLED, и при метании исключений, если это не включено, перенаправлять на мелкую страницу, иначе на уродливую страницу с отладочной информацией, но внимательно изучите, какую отладочную информацию вы показываете на своем сервере. Надеюсь, это все прояснит.
EDIT По-видимому, мой ответ недостаточно документирован, вы должны проверить эти источники
Наконец, есть одна вещь, о которой я не говорил, поскольку я думал, что это было своего рода неявным: здравый смысл не делать этого! Вы не помещаете отладочные инструменты на своем производственном сервере по той же причине, что и их сохранение в другой среде, потому что вам нужно оставлять ненужные вещи. Любой процесс, выполняющийся на сервере, независимо от того, насколько он свет, повлияет на вашу производительность.
Я сделал несколько тестов, просто включив модуль без фактической отладки, замедляет запрос на моей машине разработки с 1 секунды до около 4 секунд
Почему же вам нужно что-то подобное? Отладка перед развертыванием на производство. Это сделает приложение медленнее.
Вы никогда не должны держать это на производстве.
Вашему приложению никогда не нужно распечатывать «те приятные сообщения отладки», так как они не очень приятны для ваших пользователей. Они являются признаком плохого тестирования, и они убьют доверие пользователей, особенно в среде предприятия / электронной коммерции.
Во-вторых, более подробную техническую информацию, которую вы раскрываете, тем больше вы можете взломать (особенно, если вы уже показываете, что на самом деле проблемы с вашим кодом!). Серверы производства должны регистрировать ошибки в файлах и никогда не показывать их.
Скорость исполнения – это ваша наименьшая забота, во всяком случае, на нее будет влиять, как и память.
Xdebug предназначен для добавления полных стековых трасс в журналы ошибок, то есть значение display_errors ini, которое, конечно же, должно быть выключено (даже в разработке я этого не хочу). Он не позволяет удаленное присоединение к отладчику, если вы не включили настройку remote_attach ini. Хотя это медленнее, если у вас есть тайная ошибка PHP, например, выделенная память Max или ошибка сегментации, это единственный способ увидеть, где она фактически была реализована.
Вы всегда можете клонировать ваш живой сервер с точно такой же конфигурацией, за исключением того, что он не будет публичным. Затем вы можете установить XDebug на него и отлаживать вещи с почти точно такими же условиями (ну, загрузка будет отличаться между реальной жизнью и клоном, но остальное будет одинаковым). В этом случае вы отлаживаете вещи в живой среде, но реальный живьем не влияет.
Примечание. Очевидно, это не относится ни к кому. Не каждый может легко клонировать сервер. Если вы используете облачные сервисы, такие как AWS и т. Д., Это будет очень просто. Если вы используете инструменты настройки сервера, такие как Ansible, Chef, Puppet для создания своего сервера, это тоже кусок пирога.
Вы никогда не должны отображать сообщения об ошибках отладки на производственном сервере. Это уродливо для ваших пользователей, а также для безопасности. Я уверен, что это сделает его еще медленнее.
Вы можете использовать XDebug в производстве, если вы «сделаете это правильно». Вы можете включить расширение в режиме «бездействия», который запускается только через запросы, которые проходят через определенное имя HOSTS. Подробнее здесь:
http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug