A habilitação do XDebug em um servidor de produção tornará o PHP mais lento?

O título praticamente diz tudo … é uma má idéia? Gostaria de ter as mensagens de debugging aprimoradas que o XDebug fornece no servidor.

[editar] Apenas para deixar as coisas claras. Estou ciente de que há riscos de segurança envolvidos. Talvez eu deveria complementar minha pergunta e dar razões mais precisas para que eu desejasse fazer isso.

Nosso servidor de produção hospeda também uma plataforma de teste. Às vezes, usamos isso para testar as coisas em um ambiente o mais próximo possível da produção. A principal coisa que estou procurando é o var_dump() aprimorado do XDebug.

Este não é um servidor de aplicativos para aplicativos de alto tráfego e o desempenho não é tão grande. Eu estava apenas curioso se o desempenho fosse visivelmente impactado pelo XDebug.

Além disso, acho que poderia habilitá-lo apenas para o VirtualHost que define os sites de teste.

Além do fato óbvio de que as mensagens de debugging não podem ser exibidas em um aplicativo que já está em produção, e também o fato de que eu não sei por que você gostaria disso, há algumas coisas realmente ruins nisso.

O primeiro é que quando você adiciona o comportamento de debugging ao seu servidor, o mecanismo de debugging “anexa” ao processo PHP e recebe mensagens do motor para parar nos pontos de interrupção, e isso é MAU, porque introduz um golpe de alto desempenho para ter outro processo parando ou “mantendo” o analisador de PHP.

Outro grande problema é que quando um depurador está instalado, pelo menos a maioria deles, eles tendem a ter o hábito desagradável de abrir portas em seu servidor, porque não são destinados a ambientes de produção e, como você pode saber, qualquer software que se abra As portas do seu servidor estão abrindo uma porta para qualquer hacker.

Se você precisar de debugging no seu código, em seu aplicativo, implemente um sistema de debugging, se não estiver disponível, já que a maioria das estruturas possui isso. Defina um valor de configuração, diga DEBUG_ENABLED e ao lançar exceções, se não estiver habilitado, redirect para uma página mesquinha, senão para uma página feia com informações de debugging, mas cuide bem as informações de debugging que você exibe em seu servidor. Espero que isso esclareça tudo.

EDITAR Como aparentemente minha resposta não está documentada o suficiente, você deve verificar essas fonts

  • PHPs XDebug rastreando despesas gerais na produção
  • Cuidado: XDebug pode distorcer seus números de desempenho

Finalmente, há uma coisa que eu não disse, pois achava que era meio implícito: é bom senso não fazê-lo! Você não coloca instrumentos de debugging no seu servidor de produção pelo mesmo motivo que os mantém em um ambiente diferente, porque você precisa manter coisas desnecessárias longe disso. Qualquer processo executado em um servidor, não importa quão claro seja, afetará seu desempenho.

Desacelerar pelo fator 4

Eu fiz alguns testes, apenas habilitando o módulo, sem realmente depurar, reduz o atraso na minha máquina de desenvolvimento de 1 segundo para cerca de 4 segundos

Por que diabos você quer algo assim? Depurar antes de implantar na produção. Isso tornará o aplicativo mais lento.

Você nunca deve manter isso na produção.

Sua aplicação nunca precisa imprimir “essas mensagens de debugging agradáveis”, pois elas não são agradáveis ​​aos seus usuários. Eles são um sinal de testes ruins e eles vão matar a confiança dos usuários, especialmente em um ambiente empresarial / comércio eletrônico.

Em segundo lugar, as informações técnicas mais detalhadas que você revela, quanto mais você provavelmente será pirateado (especialmente se você já está revelando que existem, de fato, problemas com seu código!). Os servidores de produção devem registrar erros nos arquivos e nunca exibi-los.

A velocidade de execução é a sua menor preocupação, de qualquer forma, será afetada por ela, assim como a memory.

O Xdebug é para adicionar traços de pilha completos aos logs de erro, que é o valor ini do display_errors, que, claro, deve estar Desligado (mesmo em desenvolvimento, eu não quero isso). Não permite anexação remota a um depurador, a menos que você ative a configuração remote_attach ini. Embora seja mais lento, se você tiver um erro de mistério PHP como a memory máxima alocada ou a falha de Segmentação, esta é a única maneira de ver onde realmente aconteceu.

Você sempre pode clonar seu servidor ao vivo com exatamente a mesma configuração, exceto que não seria público. Então você pode instalar o XDebug sobre ele e depurar as coisas com quase exatamente as mesmas condições (bem, a carga será diferente entre a vida real e o clone, mas o resto será o mesmo). Nesse caso, você depura as coisas em um ambiente ao vivo, mas a vida real não é afetada.

Nota: Obviamente, não se aplica a ninguém. Nem todos podem facilmente clonar um servidor. Se você usar serviços em nuvem como o AWS etc., seria muito fácil. Se você usa ferramentas de configuração do servidor como Ansible, Chef, Puppet para construir seu servidor, isso também é um pedaço de bolo.

Você pode usar o XDebug na produção se você “fizer isso corretamente”. Você pode habilitar a extensão em um modo “dormente” que só é trazido para viver através de solicitações que passam por um nome HOSTS específico. Veja detalhes aqui:

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

Você nunca deve exibir mensagens de erro de debugging em um servidor de produção. É feio para seus usuários e também um risco de segurança. Tenho certeza que isso vai tornar um pouco mais lento também.