Je sais que Xdebug ralentit PHP, mais sur mon PC Ubuntu 16, cela ralentit beaucoup PHP uniquement lorsque l'écoute de Xdebug est activée dans PhpStorm, dans d'autres cas, la vitesse est bonne.
Mais maintenant, j'essaie d'installer un environnement de développement sur MacOS avec Docker.
Donc en quelques mots: j'ai trouvé un script de référence. Lorsque je vérifie la vitesse de PHP avec Xdebug installé et activé, il faut environ 28 à 32 secondes pour l'exécuter. Si je construis un conteneur sans Xdebug installé et configuré, le temps d'exécution du script est d'environ 0,8 à 1,1 s, ce qui est 30 fois plus rapide!
Y a-t-il une chance que j'ai configuré quelque chose de mal et que le serveur envoie une «réponse Xdebug» tout le temps?
Je ne sais pas vraiment comment cela fonctionne, mais je suis sûr que cela ne devrait pas être comme ça.
J'utilise Docker, conteneur Ubuntu 16.04, PHP 7.2, Xdebug v2.9.1, Apache.
Voici mes paramètres Xdebug:
zend_extension = "/usr/lib/php/20190902/xdebug.so" xdebug.remote_enable=1 xdebug.remote_port=9003 xdebug.remote_host=host.docker.internal xdebug.idekey=PHP_STORM xdebug.remote_connect_back=off xdebug.profiler_enable = 0 xdebug.remote_autostart = 0 xdebug.remote_handler = "dbgp" xdebug.remote_mode = req
Encore une autre chose. Je suis capable de commencer le débogage avec cette icône d' écoute Xdebug , quand tous les guides disent que je devrais utiliser l'option «Ajouter une configuration» et ajouter le service Xdebug.
Pouvez-vous me dire si je fais quelque chose de mal?
3 Réponses :
J'étais confronté au même problème, il y avait un problème avec ma configuration.
Je me connectais au serveur Web via une adresse réseau distante (comme 192.168.xx.xx, 10.10.xx.xx) au lieu de l'adresse de la machine locale (comme 127.0.0.1 ou localhost).
Peut-être y avait-il des problèmes de routage dans ma configuration de docker ou dans certains autres paramètres. Bien que je ne sois pas arrivé à la cause profonde, cela a résolu mon problème.
Cela a fonctionné et mon débogage est devenu rapide.
Ce n'est pas le cas pour moi. J'utilise des adresses locales.
J'ai eu le même problème jusqu'à ce que je découvre que l'extension Xdebug dans Chrome en était la cause. S'il est désactivé, les temps de chargement sont corrects, s'il est activé, un rechargement de page prenait souvent plus de 60 secondes par rapport à 5 avec Xdebug désactivé. Cela ne faisait aucune différence si Xdebug dans PHPStorm ou Container était activé ou non.
J'ai utilisé docker-compose pour basculer entre deux instances php (l'une avec xdebug et l'autre sans elle)
Les conteneurs Apache XDEBUG_SESSION la valeur du cookie PHPSTORM ( PHPSTORM par défaut)
Voici la partie intéressante de la configuration
<If "%{HTTP_COOKIE} =~ /XDEBUG_SESSION=${XDEBUG_COOKIE_VALUE}/">
SetHandler "proxy:fcgi://php_xdebug:9000"
</If>
<Else>
SetHandler "proxy:fcgi://php:9000"
</Else>
Script de composition Docker
https://github.com/unlocomqx/conditional-xdebug-fpm-docker
Au moins, vous pourriez faire, c'est d'exécuter la dernière version: 2.9.2. Dans votre cas, vous avez deux problèmes: Docker ralentit encore plus les choses, macOS ralentit encore plus les choses. Dans tous les cas, lorsque vous déboguez, le débogueur fonctionne, donc je serais plus lent. Cependant, la différence ne devrait pas être si grande que si vous utilisez un cadre vraiment inefficace ou quelque chose du genre.
@Derick J'utilise en fait un énorme CMS mais je ressens vraiment une énorme différence entre le débogueur installé et non installé. Je suis d'accord avec la vitesse de docker sur MacOS, mais le débogueur rend impossible le travail. Je vais bien s'il était de cette vitesse lorsque j'écoute le débogueur (car il fonctionne sur mon PC Ubuntu) mais il a la même vitesse tout le temps.
@ ДимаЛизунов Lorsque Xdebug se connecte à PhpStorm, l'EDI configurera certains paramètres, définira des points d'arrêt et le laissera simplement s'exécuter - aucune communication ne devrait avoir lieu ici jusqu'à la toute fin lorsque Xdebug dit "J'ai terminé / session terminée", sauf si ont des points d'arrêt conditionnels que l'EDI doit évaluer chaque fois que cette ligne est exécutée. Activez le journal Xdebug et vérifiez ce qu'il a à dire à ce sujet - il affichera si l'EDI tente de définir des points d'arrêt, etc.
@ ДимаЛизунов Concernant "Icône d'écoute de débogage vs Configuration d'exécution / débogage" - il n'y a pas de différence ici. Lorsque vous créez la configuration et appuyez sur "Déboguer", il commence à écouter et passe les paramètres nécessaires à l'exécutable URL / CLI pour démarrer la session de débogage. Lorsque vous utilisez simplement "l'icône de poignée de téléphone", il écoute toujours sur le port Xdebug les connexions entrantes mais vous contrôlez le paramètre de cookie / URL "debug me" ou un autre indicateur "debug this request".
@ ДимаЛизунов Je ne vais pas commenter Docker et Mac. Je suis sous Windows, fonctionnant généralement sur IIS local pour la plupart des sites (versions PHP nts, x64), utilisant parfois la machine virtuelle appropriée sous VMware. Pour l'exécution native locale, la différence avec Xdebug activé (dans php.ini; pas de tentatives de débogage) est environ 2 .. 2,3 fois plus lente que si l'extension xdebug est désactivée / commentée (c'est environ 1,5 ans de tests que j'ai faits; en utilisant PHP 7.2 IIRC). Je ne peux que suggérer de vérifier le journal Xdebug et de voir ce qu'il fait quand il essaie de déboguer (établit ou tente d'établir une session de débogage).
@LazyOne merci pour vos commentaires. Je vérifierai cela un peu plus tard. mais comme vous l'avez mentionné, l'activation de xdebug devrait rendre le code exécuté 2 fois plus lentement, mais pas 30 fois. J'essaierai de vérifier les journaux.
Dans la dernière version de Windows, PHP 7.2 et Docker et Xdebug, j'ai exactement le même problème. C'est terriblement lent, ce qui rend impossible le débogage. Il faut plus d'une minute pour démarrer le débogage réel. Celui que vous pouvez tracer la première ligne, il peut être poursuivi normalement.
docker ralentit tout ... même vous n'accepterez pas cela
juste deviner dans le noir ici, deux plans: 1. XDebug ajoute-t-il simplement trop sur l'empreinte mémoire globale, donc le conteneur commence à changer? 2: Ce qui me fait me demander, c'est que vous avez activé Xdebug sans démarrage automatique mais vous dites qu'il est toujours en cours d'exécution? comment avez-vous initié la session? se pourrait-il que le profilage (la configuration montre qu'il est désactivé mais juste pour être sûr?) ou le mode de traçage est également en cours d'exécution? Heureux de voir que @Derick est également actif ici et se lance en premier en tant que créateur de Xdebug <3
@LazyOne avez-vous compris cela? Je suis sur un Mac, PHP 7.4 et XDebug 3 et j'ai exactement ce problème. Temps de chargement de la page: plus de 30 secondes lorsqu'il est actif, moins de 2 inactifs. J'exécute juste la configuration de débogage la plus basique - sans même utiliser le profilage à distance.
@badcrocodile Désactiver le runtime Xdebug (pour v3 -
xdebug.mode=off) - mieux? Je veux dire: à quelle vitesse par rapport à l'avoir complètement désactivé (non chargé) et en mode de débogage normal. Combien de temps il sera plus lent en modexdebug.mode=develop? En tout cas: dans mes projets, c'est assez rapide (je veux dire: pas de retards ÉNORMES comme certains les gars voient ici)@badcrocodile Ce que j'ai remarqué cependant .. que lors du débogage dans PhpStorm .. cela peut être lent pour plusieurs raisons: 1) avoir trop de points d'arrêt; 2) Vous avez BEAUCOUP de constantes globales / variables globales définies; 3) ont beaucoup de variables locales (énormes tableaux, gros objets, beaucoup de montres dans PhpStorm) - tout cela doit être rafraîchi après chaque étape.
@badcrocodile 4) Certains paramètres Xdebug généreront beaucoup plus d'informations de contexte / de débogage (les valeurs par défaut sont correctes, c'est lorsque l'utilisateur les ajuste pour qu'elles soient plus verbeuses / détaillées - consultez-les: xdebug.org/docs/all_settings ). Vérifiez également php.watch/articles/xdebug2-vs-3-benchmark