Будет ли включение XDebug на рабочем сервере замедлять работу PHP?
Название в значительной степени говорит обо всем... это плохая идея? Я хотел бы иметь расширенные сообщения отладки, которые XDebug предоставляет на сервере.
[править] Просто чтобы прояснить ситуацию. Я знаю, что есть риски безопасности. Возможно, я должен дополнить свой вопрос и привести более точные причины, почему я хотел бы сделать это.
Наш производственный сервер также содержит платформу для тестирования. Иногда мы используем его для тестирования вещей в среде, максимально приближенной к производственной. Главное, что я ищу, это использование улучшенного XDebug var_dump(),
Это не сервер приложений для приложений с высоким трафиком, и производительность не так уж велика. Мне было просто любопытно, заметно ли повлияет производительность XDebug.
Кроме того, я думаю, я мог бы включить его только для VirtualHost, который определяет сайты тестирования.
12 ответов
Помимо очевидного факта, что сообщения отладки не могут быть отображены в приложении, которое уже находится в производстве, а также того факта, что я не знаю, зачем вам это нужно, есть несколько вещей, которые действительно плохие.
Во-первых, когда вы добавляете поведение отладки на ваш сервер, механизм отладки "присоединяется" к процессу PHP и получает сообщения от механизма, чтобы остановиться на точках останова, а это ПЛОХО, потому что вводит удар высокой производительности, чтобы иметь другой процесс остановка или "сохранение" парсера PHP.
Еще одна большая проблема заключается в том, что при установке отладчика, по крайней мере, у большинства из них, как правило, появляется неприятная привычка открывать порты на вашем сервере, поскольку они не предназначены для производственных сред и, как вы, возможно, знаете, любого программного обеспечения, которое открывается. Порты на вашем сервере открывают двери для любого хакера.
Если вам нужно иметь отладку в своем коде, то в вашем приложении внедрите систему отладки, если она недоступна, поскольку в большинство фреймворков это встроено. Установите значение конфигурации, скажем, DEBUG_ENABLED, и при создании исключений, если не включено, перенаправьте на мелкую страницу, иначе на уродливую страницу с отладочной информацией, но позаботьтесь о том, какую отладочную информацию вы отображаете на своем сервере. Я надеюсь, что это проясняет все.
РЕДАКТИРОВАТЬ Поскольку, очевидно, мой ответ недостаточно документирован, вы должны проверить эти источники
- Затраты на трассировку XDebug в производственной среде PHP
- Осторожно: XDebug может исказить ваши показатели производительности
Наконец, есть одна вещь, которую я не сказал, так как считал ее неявной: здравый смысл не делать этого! Вы не размещаете инструменты отладки на своем производственном сервере по той же причине, по которой вы держите их в другой среде, потому что вам нужно уберечь от них ненужные вещи. Любой процесс, работающий на сервере, независимо от того, насколько он свет, повлияет на вашу производительность.
Замедлить в 4 раза
Я провел несколько тестов, просто включив модуль, без фактической отладки, замедляя запрос на моей машине для разработки с 1 до 4 секунд.
Полное удаление xdebug (даже если оно не было включено) увеличило загрузку страницы на 50% (с 60 до 30 мс). У нас был xdebug сидя "спящий" (ожидание триггера). Мы думали, что, поскольку он дремлет, это не причинит никакого вреда, но, парень, мы ошиблись.
Мы прокомментировали строку zend_extension в конфигурации php около 21:43. Средняя нагрузка также снизилась с 0,4 до 0,2 на ядро:
С какой стати ты хочешь что-то подобное? Отладка перед развертыванием в производство. Это замедлит работу приложения.
Xdebug 3
XDebug 3 теперь позволяет отключить его, чтобы накладные расходы были близки к 0: https://xdebug.org/docs/install#mode
Вы можете использовать конфигурацию ниже в рабочей среде, чтобы установить xdebug с минимальными издержками, близкими к 0:
[xdebug]
xdebug.mode=off
Ничего не включено. Xdebug не работает, кроме проверки включения функций. Используйте этот параметр, если вы хотите, чтобы накладные расходы были близки к нулю.
Я знаю, что это старый пост, но поскольку проблема с Xdebug все еще существует 10 лет назад, я хотел бы указать на соответствующий отчет об ошибке (закрыт как WONTFIX NOTABUG): https://bugs.xdebug.org/view.php?id=1668
Tl;dr:
Простая установка xdebug (в linux @least) замедлит весь php на сайте до обхода, с числом обращений от 2x до 20x, даже если все флаги выключены. НЕ УСТАНАВЛИВАЙТЕ xdebug В ПРОИЗВОДСТВЕ - НИКОГДА. А еще лучше изучить менее навязчивые варианты отладки.
Xdebug предназначен для добавления полных трасс стека в журналы ошибок, то есть значение ini display_errors, которое, конечно, должно быть выключено (даже в разработке я не хочу этого). Он не разрешает удаленное подключение к отладчику, если вы не включите параметр ini remote_attach. Хотя это медленнее, если у вас есть таинственная ошибка PHP, такая как выделение максимальной памяти или ошибка сегментации, это единственный способ увидеть, где это произошло на самом деле.
Вы всегда можете клонировать ваш живой сервер с точно такой же конфигурацией, за исключением того, что он не будет публичным. Затем вы можете установить на него XDebug и отлаживать вещи практически с одинаковыми условиями (ну, нагрузка в реальной жизни и клоне будет отличаться, но в остальном будет то же самое). В этом случае вы отлаживаете вещи в живой среде, но реальная жизнь не затрагивается.
Примечание: очевидно, это не относится ни к кому. Не каждый может легко клонировать сервер. Если вы используете облачные сервисы, такие как AWS и т. Д., Это будет очень просто. Если вы используете инструменты для настройки сервера, такие как Ansible, Chef, Puppet, для создания своего сервера, то это тоже будет просто.
Вы никогда не должны держать это на производстве.
Ваше приложение никогда не должно распечатывать "эти хорошие отладочные сообщения", так как они совсем не нравятся вашим пользователям. Они являются признаком плохого тестирования и убьют доверие пользователей, особенно в среде предприятия / электронной коммерции.
Во-вторых, чем более подробную техническую информацию вы раскрываете, тем больше вероятность того, что вас взломают (особенно если вы уже раскрываете, что на самом деле существуют проблемы с вашим кодом!). Производственные серверы должны регистрировать ошибки в файлах и никогда не отображать их.
Скорость выполнения - ваша наименьшая проблема, в любом случае это повлияет на нее, равно как и на память.
Я проверил влияние на производительность с помощью этого инструмента тестирования php. Отказ от ответственности Я создал инструмент.
Ответ - модуль xdebug значительно замедляет выполнение кода: от 2x до 7x раз в зависимости от теста. Вот мои результаты:
# env information
php version : 7.4.5
platform : WINNT x64
# disable xdebug extension in php.ini
$ php src/benchmark.php --iterations 1000 --time-per-iteration 50 --save xdebug_off
# enable xdebug extension
$ php src/benchmark.php --iterations 1000 --time-per-iteration 50 --save xdebug_on
# compare
$ php src/compare.php --file1 benchmark_xdebug_off_20201127-0946.txt --file2 benchmark_xdebug_on_20201127-0939.txt
------------------------------------------------
test_math OFF ON
mean : 3762 531 -85.9%
median : 4226 568 -86.6%
mode : 4655 596 -87.2%
minmum : 918 188 -79.5%
maximum : 4722 612 -87.0%
quartile 1 : 3081 490 -84.1%
quartile 3 : 4580 595 -87.0%
IQ range : 1498 105 -93.0%
std deviation : 984 87 -91.1%
normality : 11.0% 11.0%
------------------------------------------------
test_strings
mean : 1419 677 -52.3%
median : 1521 688 -54.7%
mode : 1580 974 -38.4%
minmum : 537 90 -83.2%
maximum : 1629 1071 -34.3%
quartile 1 : 1319 452 -65.7%
quartile 3 : 1582 892 -43.6%
IQ range : 262 440 67.8%
std deviation : 226 248 9.8%
normality : 6.6% 6.6%
------------------------------------------------
test_loops
mean : 8131 1208 -85.1%
median : 8617 1240 -85.6%
mode : 9109 1407 -84.6%
minmum : 3167 589 -81.4%
maximum : 9666 1435 -85.2%
quartile 1 : 7390 1116 -84.9%
quartile 3 : 9253 1334 -85.6%
IQ range : 1863 217 -88.3%
std deviation : 1425 164 -88.4%
normality : 5.6% 5.6%
------------------------------------------------
test_if_else
mean : 279630 31263 -88.8%
median : 293553 31907 -89.1%
mode : 303706 37696 -87.6%
minmum : 104279 12560 -88.0%
maximum : 322143 37696 -88.3%
quartile 1 : 261977 28386 -89.2%
quartile 3 : 307904 34773 -88.7%
IQ range : 45927 6387 -86.1%
std deviation : 39034 4405 -88.7%
normality : 4.7% 4.7%
------------------------------------------------
test_arrays
mean : 5705 3275 -42.6%
median : 5847 3458 -40.9%
mode : 6040 3585 -40.6%
minmum : 3366 1609 -52.2%
maximum : 6132 3645 -40.6%
quartile 1 : 5603 3098 -44.7%
quartile 3 : 5965 3564 -40.3%
IQ range : 361 465 28.8%
std deviation : 404 394 -2.5%
normality : 2.4% 2.4%
------------------------------------------------
Вы никогда не должны отображать сообщения об ошибках отладки на производственном сервере. Это отвратительно для ваших пользователей, а также представляет угрозу безопасности. Я уверен, что это будет немного медленнее.
Вы можете использовать XDebug в производстве, если вы "делаете это правильно". Вы можете включить расширение в "спящем" режиме, который активируется только через запросы, которые проходят через определенное имя HOSTS. Вот подробности здесь:
http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug