l'activation du débogage distant de xdebug ralentit considérablement le serveur Apache
Si j'active xdebug en définissant xdebug.remote_enable=1, le serveur Apache devient très lent; une fois que je change le réglage en 0, c'est normal.
J'ai trouvé une même question ici: XDebug vraiment lent , mais la réponse n'est pas utile. Je n'ai pas activé le profilage:
xdebug.profiler_enable=0
xdebug.auto_trace = 0
xdebug.trace_output_dir = /tmp/xdebug
xdebug.trace_output_name = trace.%c
J'ai vérifié qu'il n'y avait rien dans le dossier/tmp/xdebug.
Lorsque le débogage distant de xdebug est activé et que j'active l'écoute de débogage dans PHPStorm, il faut un certain temps pour s'arrêter au point d'arrêt, mais pas aussi lentement que la désactivation de l'écoute de débogage de phpstorm.
Mon environnement est: php + Apache + xdebug sur la machine virtuelle Centos locale, ma base de données mysql et PHPStorm sont sur le bureau Windows pour le développement. MySQL n'est pas lent.
Appréciez l'aide.
Dans mon cas, cela a été causé par avoir
xdebug.remote_autostart = 1
défini dans php.ini. Ceci oblige xdebug à essayer de se connecter au débogueur distant à chaque requête. J'avais des styles PHP gérés, auto_preppend_file et d'autres fichiers PHP dans la demande et pour chacun d'entre eux, il a attendu environ 2 secondes, ce qui a abouti à sth. comme 15 secondes ou plus. Réglage
xdebug.remote_autostart = 0
résolu le problème complètement. xdebug connecte uniquement lorsque le cookie de débogage est présent. Veuillez noter que vous devez supprimer le cookie de débogage/param si vous n'êtes pas en session de débogage pour que ce correctif fonctionne.
Expérimenté également avec de faibles performances avec XDebug (chargement de Captcha en 6 secondes au lieu de millisecondes)
Désactivez le profileur et le temps de chargement a été divisé par 3. .. Encore lent, mais déjà mieux.
xdebug.profiler_enable = 0
Juste comme référence supplémentaire ... au cas où quelqu'un aurait le même problème/un problème similaire ... (délai d'attente de 60 secondes)
La première vérification double xdebug.remote_autostart est désactivée pour éviter la connexion automatique.
Comme @LazyOne l'a fait remarquer, et @Tomáš Fejfar l'explique également.
xdebug.remote_autostart
Type: booléen, valeur par défaut: 0
Normalement, vous devez utiliser une variable HTTP GET/POST spécifique pour lancer le débogage distant ( voir Débogage distant ). Lorsque ce paramètre est défini sur 1, Xdebug tentera toujours de démarrer une session de débogage distante et de se connecter à un client}, même si la variable GET/POST/COOKIE n'était pas présente.
Avec cela, je récupère ma vitesse normale lorsque le cookie de débogage n'était pas présent ...
Mais! ... Je reçois toujours très lente réponse (délai d'attente de 60 secondes) du serveur lorsque le cookie a été activé manuellement.
Donc, après avoir lu la Documentation Xdebug et vérifié ma configuration,
Je découvre que j'avais activé xdebug.remote_connect_back
xdebug.remote_connect_back
Type: booléen, valeur par défaut: 0, introduite dans Xdebug> 2.1
Si activé, le paramètre xdebug.remote_Host est ignoré et Xdebug essaiera de se connecter au client qui a envoyé la demande HTTP}. Il vérifie la variable $ _SERVER ['REMOTE_ADDR'] pour savoir quelle adresse IP utiliser. Veuillez noter qu'aucun filtre n'est disponible et que toute personne pouvant se connecter au serveur Web pourra alors démarrer une session de débogage, même si son adresse ne correspond pas à xdebug.remote_Host.
Tous les appels sur le serveur essayaient donc d’être débogués, ce qui le rendait très lent et peu sûr.
Désactivez cette option et vérifiez que j'ai bien défini xdebug.remote_Host pointant vers ma machine, j'ai obtenu une réponse acceptable ~ 1sec. Et uniquement lorsque le cookie est activé.
En bref, mon fichier de configuration se termine comme ceci:
zend_extension = "/absolute/path/to/your/xdebug-extension.so"
xdebug.remote_enable = 1
xdebug.remote_autostart = 0
xdebug.remote_connect_back = 0
xdebug.remote_Host = "192.168.1.2"
xdebug.remote_port = 9000
xdebug.remote_handler = "dbgp"
xdebug.remote_mode = req
xdebug.remote_log = "/tmp/xdebug.log"
Remarque: j'ai apporté ces modifications dans le fichier etc/php5/conf.d/xdebug.ini et non dans php.ini
Modifier:
Comme @ Riimu & @ jdunk faites-le remarquer grâce aux deux , vous pouvez également définir:
* voir les commentaires pour plus de détails
xdebug.remote_cookie_expire_time = 0
// or
xdebug.remote_cookie_expire_time = -9999
J'utilise PHPStorm 7.1 et le serveur Apache installé par Xampp 1.8.2, le tout sous Windows 8.1. J'ai constaté une interopérabilité lente entre Chrome et PHPStorm en mode débogage lors de la définition de points d'arrêt.
La vitesse a été considérablement améliorée en installant la dernière version de la dll XDebug (utilisez l'assistant XDebug pour déterminer quelle version télécharger), copiez la dll dans votre répertoire php/ext et modifiez le fichier php.ini afin que la nouvelle dll XDebug sera chargé. Arrêtez Apache et voyez la différence.
J'ai pu vérifier qu'un gain de performances similaire avait été obtenu lors du débogage d'une application Web avec Eclipse (Juno avec PDT) à l'aide du navigateur Web interne Eclipse.
Aussi, si vous voulez laisser xdebug.remote_autostart = 1 activé tout le temps, essayez dans vos paramètres Phpstorm d'augmenter le nombre maximal de sections simultanées. Cela devrait réduire les blocages et les suspensions, mais aura néanmoins un impact sur les performances basé sur mon expérience.
Dans mon cas, les faibles performances ont été provoquées par la définition de plus de 200 points d'arrêt dans PHPStorm, qui ont été évalués à chaque demande par xdebug.
La suppression de ces points d'arrêt dans PHPStorm a augmenté les performances de 60 à 6 secondes par demande.
Il est probable que certains délais d'attente de mise en réseau se produisent ici. La meilleure façon de savoir ce qui ne va pas est d'essayer de déboguer un script en ligne de commande. Si le problème persiste, utilisez strace pour voir à quoi il se bloque:
export XDEBUG_CONFIG="idekey=yourname"
strace -tt -o /tmp/strace.log php full/path/to/script.php
Regardez ensuite /tmp/strace.log et voyez où se produit le ralentissement.
Parfois, si d'autres services fonctionnent sur le port 9000, Xdebug ne pourra pas se connecter à son serveur sur le port 9000, ce qui ralentira le processus car le délai d'attente sera dépassé à chaque requête.
Essayez de changer le port par défaut (9000) où xDebug écoute, j’ai utilisé 9090 pour l’exemple mais vous pouvez utiliser n’importe quel port libre que vous avez:
xdebug.remote_port=9090
Ensuite, n'oubliez pas de changer le port sur lequel xDebug écoute sur votre IDE, j'utilise le code Visual Studio:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.Microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9090,
"log": true
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9090
}
]
}