posted by Pascal CESCATO on PHP

Parmi les outils de développement pour PHP, xdebug est un must-have. Debogueur mais également profileur, xdebug est une sorte de couteau suisse du développeur, nous allons voir comment l’installer, le configurer et surtout, l’utiliser.

Installation de Xdebug

Prérequis : php5-dev doit être installé sur votre serveur web.

Installation sous Linux

Commencez par télécharger la dernière version de Xdebug (vous trouverez le lien sur la page downloads) :

wget http://www.xdebug.org/files/xdebug-[version].tgz

Puis décompressez l’archive :

tar -xvzf xdebug-[version].tgz

Rendez-vous dans le répertoire où vous avez décompressé votre archive :

cd xdebug-[version]

et pour finir exécutez les commandes suivantes :

phpize
./configure
make
make install

Voilà, si aucun message d’erreur n’est venu assombrir votre ciel, Xdebug est installé sur votre serveur. Reste maintenant à le configurer avant de pouvoir l’utiliser…

Installation sous Windows

Téléchargez la dll ici : http://www.xdebug.org/download.php.
Prenez la version de Xdebug correspondant à votre version de PHP, puis copiez la dans le répertoire d’extension de votre serveur (généralement \ext\).

Configuration de Xdebug

La configuration de Xdebug s’effectue dans php.ini, nous allons donc ouvrir ce fichier :

vim /etc/php5/apache2/php.ini

ou ouvrez-le avec un éditeur de texte sous Windows.

Si vous ne trouvez pas votre fichier php.ini, vous pouvez le localiser en tapant (sous Linux) la commande suivante :

locate php.ini

Ajoutez la ligne suivante sous Linux :

zend_extension="/chemin_vers/xdebug.so"

ou celle-ci sous Windows :

zend_extension_ts="c:\chemin_vers\php_xdebug-[version].dll"

Si vous avez une erreur avec zend_extension[_ts] utilisez extension mais Xdebug ne sera pas chargé en tant qu’extension Zend, et que certaines fonctionnalités peuvent ne pas être disponibles.

Rajoutez ensuite les lignes qui suivent (toujours dans le fichier php.ini) :

xdebug.remote_enable = 1
xdebug.remote_port = 9000

Si vous souhaitez que Xdebug soit lancé à chaque exécution d’un script PHP, ajoutez encore :

xdebug.default_enable=on

Pour accéder aux ressources Xdebug depuis votre serveur uniquement, configurez l’option xdebug.remote_host ainsi :

xdebug.remote_host=localhost

Si par contre vous désirez y accéder depuis votre poste :

xdebug.remote_host=xxx.xxx.xxx.xxx

Il existe d’autres paramètres de configuration, ce lien vous les fera découvrir.

Xdebug est configuré, relancez le serveur Apache pour que les nouveaux paramètres soient pris en compte :

/etc/init.d/apache2 restart

Utilisation de Xdebug

Débogage

L’une des fonctions les plus connues de Xdebug est sa version améliorée de var_dump. Ci-dessous l’affichage simple, sans Xdebug (mais formaté avec la balise pre), puis avec Xdebug (plus besoin de formatage) :

L’autre avantage de Xdebug (en ce qui concerne le débogage) est sa présentation sous forme de tableau des erreurs, avec les principaux indicateurs utiles : le type d’erreur, le fichier, la ligne, ainsi que la durée d’exécution, la mémoire utilisée… Pratique pour trouver son erreur, et la corriger.

Profilage

Il n’est pas aisé d’exploiter les informations fournies par Xdebug à partir des rapports bruts. Divers outils ont été développés pour apporter plus de convivialité à leur lecture :
KCachegrind sous Linux / KDE, WinCacheGrind sous Windows, enfin webgrind pour tous. À noter que webgrind ne fonctionnera que si vous avez chargé Xdebug en tant qu’extension Zend.

KCachegrind et WinCacheGrind

KCachegrind n’est malheureusement disponible que sous Linux, mais il est l’outil de référence pour le profilage – enfin, pour la lecture des fichiers de profilage. Son homologue pour Windows, WinCacheGrind, est loin d’être aussi complet et convivial. Nous nous attarderons donc sur le troisième outil, webgrind, utilisable dans tous les mondes.

webgrind

L’interface de webgrind est simple et agréable, le logiciel se pilote de manière intuitive. On commence par choisir dans une barre de menu le niveau de détail désiré (de 10 à 100%), le fichier de profilage à visualiser, l’unité de mesure (pourcentage, millisecondes ou microsecondes) :

Après un temps de latence (pour la compilation des données et leur rendu), webgrind va afficher un graphique (très simple) qui permet de se rendre compte de manière visuelle du temps d’exécution du script, en différenciant les appels à des fonctions PHP natives, à des classes, les require et include…

Enfin le panneau principal permet de tracer l’exécution pas à pas :

Pour chaque fonction, le nombre d’invocations, le temps d’exécution et le coût de l’appel (en pourcentage du temps global d’exécution). À partir de ce tableau, vous pourrez repérer les appels les plus coûteux : inutile de s’attarder sur les 1500 appels à une fonction qui ne prennent que 1% du temps global d’exécution. Par contre votre fonction customisée qui à elle seule monopolise 75% du temps d’exécution, est-elle vraiment optimisée ? Vous pouvez descendre dans les entrailles de la fonction en cliquant sur la petite flèche à gauche : en descendant ainsi de niveau en niveau, vous pourrez trouver quels sont les appels à optimiser.

Enfin vous allez voir cette icone qui permet d’afficher le code source du script (le fichier complet), et celle-ci qui affiche la ligne de code dans son contexte. Ce qui peut être une aide précieuse pour le profilage…

Un exemple concret : en profilant le code d’une de mes classes, je me suis aperçu du temps occupé par les expressions régulières. Je faisais en effet appel à des motifs de type #(expression)#i. Après un strtolower avant d’éclater ma chaîne et une modification du motif : #(expression)#U, j’ai gagné 35% du temps d’exécution de ma classe, sans sacrifier aucune de ses fonctionnalités.

Tags: bonnes pratiques, débogage, debug, optimisation, php, profilage, xdebug