L'activation de XDebug sur un serveur de production ralentira-t-elle PHP?
Le titre dit à peu près tout...est-ce une mauvaise idée ? J'aimerais avoir les messages de débogage améliorés que XDebug fournit sur le serveur.
[edit] Juste pour mettre les choses au clair. Je suis conscient des risques de sécurité impliqués. Peut-être devrais-je compléter ma question et donner des raisons plus précises pour lesquelles je voudrais le faire.
notre serveur de production héberge également une plate-forme de test. Parfois, nous l'utiliser pour tester des choses sur un environnement aussi proche de production possible. La principale chose que je cherche est d'utiliser xdebug's enhanced var_dump().
ce n'est pas un serveur d'applications pour les applications à fort trafic et la performance n'est pas un gros problème. J'étais juste curieux si la performance serait sensiblement impacté par XDebug.
En outre, je suppose que je pourrais l'activer seulement pour le VirtualHost qui définit les sites de test.
8 réponses
outre le fait évident que les messages de débogage ne peuvent pas être affichés dans une application qui est déjà en production, et aussi le fait que je ne sais pas pourquoi vous aimeriez ça, il y a quelques choses vraiment mauvaises à ce sujet.
la première est que lorsque vous ajoutez un comportement de débogage à votre serveur, le moteur de débogage "se fixe" au processus PHP et reçoit des messages du moteur pour s'arrêter aux points de rupture, et C'est mauvais, parce que introduit un coup de haute performance pour avoir un autre arrêter ou "conserver" L'analyseur PHP.
un autre gros problème est que lorsqu'un débogueur est installé, du moins la plupart d'entre eux, ils ont tendance à avoir la fâcheuse habitude d'ouvrir des ports dans votre serveur, parce qu'ils ne sont pas destinés à des environnements de production, et comme vous le savez peut-être, tout logiciel qui ouvre des ports dans votre serveur ouvre une porte pour n'importe quel pirate.
si vous avez besoin de déboguer dans votre code, alors dans votre application, implémentez un système de débogage, si n'est pas disponible, puisque la plupart des cadres ont construit dans cette. Définissez une valeur de configuration, par exemple DEBUG_ENABLED et lorsque vous lancez des exceptions, si elle n'est pas activée, redirigez vers une petite page, sinon vers une page laide avec des informations de débogage, mais faites bien attention aux informations de débogage que vous affichez sur votre serveur. J'espère que cela clarifie tout.
EDIT apparemment ma réponse n'est pas assez documenté, vous devriez vérifier ces sources
- PHPs XDebug traçage des frais généraux de production
- attention: XDebug peut biffer vos numéros de performance
enfin, il y a une chose que je n'ai pas dite car je pensais que c'était implicite: c'est du bon sens de ne pas le faire! Vous ne mettez pas les instruments de débogage sur votre serveur de production pour la même raison que vous les gardez sur un environnement différent, parce que vous avez besoin de garder les choses inutiles loin de il. Tout processus tournant sur un serveur, aussi léger soit-il, aura un impact sur vos performances.
ralentir par le facteur 4
j'ai fait quelques tests juste en activant le module, sans réellement déboguer, fait ralentir une requête sur ma machine de développement de 1 seconde à environ 4 secondes
Pourquoi diable voulez-vous quelque chose comme ça? Déboguez avant de vous déployer en production. Il va rendre l'application plus lente.
vous ne devriez jamais garder cela sur la production.
votre application ne doit jamais avoir besoin d'imprimer "ces bons messages de débogage", car ils ne sont pas gentils du tout pour vos utilisateurs. Ils sont un signe de mauvais tests et ils vont tuer la confiance des utilisateurs, en particulier dans un environnement d'entreprise/commerce électronique.
Deuxièmement, les informations techniques plus détaillées que vous révélez, plus vous êtes susceptible d'être piraté (surtout si vous révélez déjà qu'Il ya en fait des problèmes avec votre code!). Les serveurs de Production devraient enregistrer les erreurs dans les fichiers et ne jamais les afficher.
la vitesse d'exécution est votre moindre préoccupation, de toute façon elle sera affectée par elle, comme le sera la mémoire.
Xdebug est pour ajouter des traces complètes de la pile aux journaux d'erreurs, c'est-à-dire la valeur display_errors ini, qui bien sûr devrait être Off (même dans le développement Je ne veux pas cela). Il n'autorise pas la connexion à distance à un débogueur à moins que vous n'activiez le paramètre ini remote_attach. Pendant qu'il est plus lent, si vous avez une erreur de mystère PHP comme Max memory assigned ou Segmentation fault, c'est la seule façon de voir où il s'est réellement passé.
vous pouvez toujours cloner votre serveur live avec exactement la même configuration, sauf qu'il ne sera pas public. Ensuite, vous pouvez installer XDebug dessus et déboguer des choses avec les mêmes conditions (bien, la charge sera différente entre la vie réelle et le clone, mais le reste sera le même). Dans ce cas, vous déboguez des choses sur un environnement réel, mais le réel n'est pas affectée.
Note: évidemment, il ne s'applique à personne. Tout le monde ne peut pas facilement cloner un serveur. Si vous utilisez des services cloud comme AWS, etc. il serait très facile. Si vous utilisez des outils de configuration de serveur tels que Ansible, Chef, Puppet pour la construction de votre serveur, c'est aussi un jeu d'enfant.
vous pouvez utiliser XDebug dans la production si vous "le faites bien". Vous pouvez activer l'extension dans un mode "dormant" qui n'est activé que par des requêtes qui passent par un nom D'hôte spécifique. Se plus de détails ici:
http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug
vous ne devriez jamais afficher des messages d'erreur de débogage sur un serveur de production. C'est moche pour vos utilisateurs et aussi un risque de sécurité. Je suis sûr qu'il fera un peu plus lent aussi.