Habilitar XDebug en un servidor de producción hará que PHP sea más lento?
El título prácticamente lo dice all...is ¿es una mala idea ? Me gustaría tener los mensajes de depuración mejorados que XDebug proporciona en el servidor.
[editar] Sólo para dejar las cosas claras. Soy consciente de que hay riesgos de seguridad involucrados. Tal vez debería complementar mi pregunta y dar razones más precisas por las que quisiera hacerlo.
Nuestro servidor de producción también alberga una plataforma de pruebas. A veces lo usamos para probar cosas en un entorno lo más cercano posible a la producción. Principal lo que estoy buscando es el uso de XDebug mejorado var_dump().
Este no es un servidor de aplicaciones para aplicaciones de alto tráfico y el rendimiento no es un gran problema. Solo tenía curiosidad si el rendimiento sería notablemente impactado por XDebug.
Además, supongo que podría habilitarlo solo para el VirtualHost que define los sitios de prueba.
8 answers
Además del hecho obvio de que los mensajes de depuración no se pueden mostrar en una aplicación que ya está en producción, y también el hecho de que no se por qué te gustaría eso, hay un par de cosas realmente malas al respecto.
La primera es que cuando añades comportamiento de depuración a tu servidor, el motor de depuración "se conecta" al proceso PHP y recibe mensajes del motor para detenerse en puntos de interrupción, y esto es MALO, porque introduce un golpe de alto rendimiento al tener otro proceso detener o" retener " el analizador PHP.
Otro gran problema es que cuando se instala un depurador, al menos la mayoría de ellos, tienden a tener el desagradable hábito de abrir puertos en su servidor, porque no están destinados a entornos de producción, y como puede saber, cualquier software que abra puertos en su servidor está abriendo una puerta para cualquier hacker alrededor.
Si necesita tener depuración en su código, entonces en su aplicación, implemente un sistema de depuración, si no está disponible, ya que la mayoría de los frameworks tienen esto incorporado. Establezca un valor de configuración, por ejemplo DEBUG_ENABLED y al lanzar excepciones, si no está habilitado, redirija a una página pequeña, de lo contrario a una página fea con información de depuración, pero tenga mucho cuidado con la información de depuración que muestra en su servidor. Espero que esto lo aclare todo.
EDIT Como al parecer mi respuesta no está suficientemente documentada, debe revisar estas fuentes
- PHPs XDebug seguimiento de sobrecarga en producción
- Cuidado: XDebug puede sesgar sus números de rendimiento
Finalmente, hay una cosa que no dije porque pensé que era algo implícito: ¡Es sentido común no hacerlo! No coloca instrumentos de depuración en su servidor de producción por la misma razón que los mantiene en un entorno diferente, porque necesita mantener las cosas innecesarias lejos de él. Cualquier proceso que se ejecute en un servidor, no importa cuán ligero sea, afectará su rendimiento.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-06-28 11:17:33
Reduzca la velocidad por factor 4
Hice algunas pruebas simplemente habilitando el módulo, sin realmente depurar, hace que se ralentice una solicitud en mi máquina de desarrollo de 1 segundo a alrededor de 4 segundos
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-09-05 09:44:47
¿Por qué diablos quieres algo así? Depurar antes de implementar en producción. Hará que la aplicación sea más lenta.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-08-19 13:23:28
Nunca deberías mantener eso en producción.
Su aplicación nunca tendrá que imprimir "esos buenos mensajes de depuración", ya que no son agradables para sus usuarios. Son un signo de pruebas deficientes y matarán la confianza del usuario, especialmente en un entorno empresarial/de comercio electrónico.
En segundo lugar, cuanto más detallada sea la información técnica que revele, más probabilidades tendrá de ser hackeado (especialmente si ya está revelando que, de hecho, hay problemas con su código!). Los servidores de producción deben registrar los errores en los archivos y nunca mostrarlos.
La velocidad de ejecución es su menor preocupación, de todos modos se verá afectada por ella, al igual que la memoria.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-08-19 13:28:43
Xdebug es para agregar trazas de pila completa a los registros de errores, es decir, el valor display_errors ini, que por supuesto debería estar desactivado (incluso en desarrollo no quiero esto). No permite el archivo adjunto remoto a un depurador a menos que habilite la configuración remote_attach ini. Si bien es más lento, si tiene un error misterioso de PHP como Max memory allocated o Segmentation fault, esta es la única forma en que verá dónde se encuentra realmente.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-15 00:02:07
Siempre podría clonar su servidor en vivo con la misma configuración, excepto que no sería público. Luego puede instalar XDebug en él y depurar las cosas con casi exactamente las mismas condiciones (bueno, la carga será diferente entre la vida real y el clon, pero el resto será el mismo). En ese caso, debug cosas en un entorno en vivo, pero real live no se ve afectado.
Nota: Obviamente no se aplica a nadie. No todo el mundo puede clonar fácilmente un servidor. Si utilice servicios en la nube como AWS, etc. sería muy fácil. Si utiliza herramientas de configuración de servidor como Ansible, Chef, Puppet para construir su servidor, esto también es pan comido.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-10-18 08:14:17
Puede usar XDebug en producción si "lo hace bien". Puede habilitar la extensión en un modo "inactivo" que solo se activa a través de solicitudes que pasan por un nombre de HOST específico. Ver detalles aquí:
Http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-01-28 12:03:09
Nunca debe mostrar mensajes de error de depuración en un servidor de producción. Es feo para sus usuarios y también un riesgo de seguridad. Estoy seguro de que lo hará un poco más lento también.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-08-19 13:27:14