¿Permitirá XDebug en un servidor de producción hacer que PHP sea más lento?

El título casi lo dice todo … ¿es una mala idea? Me gustaría tener los mensajes de depuración mejorados que proporciona XDebug en el servidor.

[edit] Solo para aclarar las cosas. 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 me gustaría hacer esto.

Nuestro servidor de producción también alberga una plataforma de prueba. A veces lo usamos para probar cosas en un entorno lo más cercano posible a la producción. Lo principal que estoy buscando es usar var_dump() mejorado de var_dump() .

Este no es un servidor de aplicaciones para aplicaciones de alto tráfico y el rendimiento no es tan importante. Solo tenía curiosidad por saber si XDebug impactaría notablemente en el rendimiento.

Además, creo que podría habilitarlo solo para el VirtualHost que define los sitios de prueba.

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 del hecho de que no sé por qué te gustaría, hay un par de cosas realmente malas al respecto.

La primera es que cuando agrega comportamiento de depuración a su servidor, el motor de depuración se “conecta” al proceso de PHP y recibe mensajes del motor para detenerse en puntos de interrupción, y esto es MALO, porque introduce un golpe de alto rendimiento para tener otro proceso detener o “retener” el analizador de PHP.

Otro gran problema es que cuando se instala un depurador, al menos la mayoría de ellos, tienden a tener la desagradable costumbre de abrir puertos en su servidor, porque no están destinados a entornos de producción, y como usted sabrá, cualquier software que se abra los puertos en su servidor están abriendo una puerta para cualquier pirata informático.

Si necesita depurar su código, en su aplicación, implemente un sistema de depuración, si no está disponible, ya que la mayoría de los marcos tienen esto incorporado. Establezca un valor de configuración, digamos DEBUG_ENABLED y cuando genere excepciones, si no está habilitado, redirecciona a una página pequeña, sino a una página fea con información de depuración, pero cuida bien de la información de depuración que muestres en tu servidor. Espero que esto aclare todo.

EDITAR Como aparentemente mi respuesta no está suficientemente documentada, debe verificar estas fonts

  • Sobrecarga de seguimiento de PHP XDebug en producción
  • Cuidado: XDebug puede sesgar tus números de rendimiento

Finalmente, hay una cosa que no dije porque pensé que era implícita: ¡es sentido común no hacerlo! No coloque instrumentos de depuración en su servidor de producción por el mismo motivo por el que los mantiene en un entorno diferente, porque necesita mantener cosas innecesarias lejos de él. Cualquier proceso que se ejecute en un servidor, sin importar cuán ligero sea, afectará su rendimiento.

Disminuya la velocidad por factor 4

Hice algunas pruebas solo para permitir que el módulo, sin depurar en realidad, ralentice una solicitud en mi máquina de desarrollo de 1 segundo a alrededor de 4 segundos

¿Por qué demonios quieres algo así? Depurar antes de implementar en producción. Hará que la aplicación sea más lenta.

Nunca deberías mantener eso en producción.

Su aplicación nunca necesitará imprimir “esos agradables mensajes de depuración”, ya que no son agradables para sus usuarios. Son un signo de pruebas deficientes y matarán la confianza de los usuarios, 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 pirateado (¡especialmente si ya revela que, de hecho, hay problemas con su código!). Los servidores de producción deben registrar 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.

Xdebug es para agregar trazas de stack completas a los registros de errores, es decir, el valor de display_errors ini, que por supuesto debería estar desactivado (incluso en desarrollo, no quiero esto). No permite la conexión remota 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 Máx. Memoria asignada o Error de segmentación, esta es la única forma en que verá dónde se ha abierto.

Siempre puede clonar su servidor en vivo con exactamente la misma configuración, excepto que no sería público. Luego puede instalar XDebug en él y depurar cosas con casi exactamente las mismas condiciones (bueno, la carga será diferente entre la vida real y el clon, pero el rest será el mismo). En ese caso, depure las cosas en un entorno en vivo, pero la vida real no se ve afectada.

Nota: Obviamente no se aplica a nadie. No todos pueden clonar fácilmente un servidor. Si usa servicios en la nube como AWS, etc., sería muy fácil. Si usa herramientas de configuración de servidor como Ansible, Chef, Puppet para construir su servidor, esto también es pan comido.

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 HOSTS específico. Se detalles aquí:

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

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 también lo hará un poco más lento.