Cet article tente de décrire la méthode utilisée pour optimiser le code de Pxxo à partir des données générées par Xdebug.
On considère ici que Xdebug est déjà installé.
Activer le profiler Xdebug
Xdebug propose en standard un profiler de code pour PHP. Celui permet de tracer et chronométrer tous les appels de méthodes et de fonctions php natives ou non. Pour activer cette fonctionnalité, il suffit de modifier la configuration de Xdebug. Pour cela, on doit modifier le fichier php.ini ou le fichier xdebug.ini.
Exemple sous Linux Debian avec le fichier xdebug.ini
zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so xdebug.profiler_append = 1 xdebug.profiler_enable = 1 xdebug.profiler_output_dir = /data/thouveni/tmp xdebug.profiler_output_name = cachegrind.out.%s
Écrire un script de test
Le profiler Xdebug génère énormément d'information. Vouloir analyser une application complète me semble inapproprié tant le volume de données produites risque d'être important (plusieurs Giga). Il est donc préférable d'isoler certaines fonctionnalités pour les tester unitairement.
On utilise Xdebug pour analyser une portion de code particulière plutôt qu'une application complète.
Il est pratique de créer un script dédié à l'exécution de la portion de code que l'on a isolée. Idéalement, ce script pourra également rejouer en boucle la partie à évaluer pour mieux faire ressortir les différences entre chaque appel.
Dans le cas de Pxxo, le script dédié est le suivant :
require_once 'Pxxo/Widget/Fake.php';
$p = array();
$p['ResourcePath'] = rtrim(dirname(__FILE__), DIRECTORY_SEPARATOR).'/rsc';
$p['ResourceURL'] = rtrim(dirname($_SERVER['PHP_SELF']), DIRECTORY_SEPARATOR).'/rsc';
$p['Lang'] = 'fr';
$p['CacheMode'] = true;
$p['CachePath'] = sys_get_temp_dir();
for($z = 0; $z < 200; $z++) {
$o = new Pxxo_Widget_Fake($p);
$o->main();
$o->get();
}
Lancer l'évaluation
Une fois le profiler activé dans la configuration de Xdebug, il suffit de relancer son serveur pour générer des fichiers de log.
Personnellement, j'active le profiler uniquement le temps d'exécuter le script de test. Cela évite de produire inutilement de la log et garantit que la log ne contiendra que les traces de l'appel à mon script.
Bien sûr, il vaut mieux activer le profiler sur un serveur de test et non sur un serveur de production. Encore une fois, trop de requête risque de produire trop de log.
Visualiser les résultats
Xdebug produit des logs au format cachegrind. Il existe à ma connaissance 2 outils libres pour analyser ce type de fichier, l'un sous Windows WinCacheGrind et l'autre sous Linux KCachegrind.
Pour avoir utiliser les deux, je conseille l'outil Linux. Car l'outil Windows n'accepte pas les gros fichiers de log et il n'implémente pas toutes les fonctionnalités proposées par KCachegrind, notamment la génération de carte graphique.
KCachegrind propose une interface en deux parties. La première affiche la liste des appels tracés :
La seconde propose une vue détaillée de chaque appel. La vue la plus simple à exploiter est celle présentée dans l'onglet "Callee Map". On peut rapidement et visuellement identifier quels sont les sous-appels qui prennent le plus de temps.
Analyser les résultats
Les graphiques produits par KCachegrind sont peut-être jolis mais il est quand même difficile de les analyser. Voici une façon parmi d'autres de procéder.
Le but est de chercher les appels les plus couteux en temps d'exécution afin de voir si on peut améliorer les choses. Pour cela, il y a plusieurs techniques :
Technique 1.
- Trier par ordre décroissant la colonne "Self." dans la partie gauche de KCachegrind, de manière à voir tout de suite les appels qui prennent le plus de temps.
- Repérer ceux qui sont appelés le plus souvent.
- Repérer ceux qui ont la "Map Callee" avec le moins de couleurs ! Plus sérieusement, il s'agit d'identifier les appels dont le temps d'exécution propre est 4 à 5 fois plus importants que pour les sous-appels.
Technique 2.
Cette technique n'est qu'une variante de la technique précédente.
- Trier par ordre décroissant la colonne "Called" dans la partie gauche de KCachegrind, de manière à voir tout de suite les appels qui sont le plus souvent appelés.
- Repérer ceux qui ont le temps d'exécution propre les plus importants.
- Repérer ceux qui ont la "Map Callee" avec le moins de couleurs !
Exemple avec Pxxo
Si on applique la technique n°1 sur le script de test de Pxxo, on peut remarquer la fonction addCacheID :
Cette méthode prend du temps, elle est beaucoup appelée et c'est majoritairement elle qui consomme le plus par rapport à ses sous-appels.
Il convient donc de regarder le code de cette méthode afin de voir :
- si le code ne peut être amélioré
- si cette méthode est appelée à bon escient
Dans le cas Pxxo, cette méthode n'est pas appelée à bon escient, Son but est de deviner le type des paramètres qu'on lui envoie afin d'en faire des chaines de caractères qu'elle stockera dans un tableau interne.
Clairement, si dans un programme, on manipule déjà une chaine de caractères, il semble inutile de vouloir deviner son type. Il vaut mieux créer une nouvelle méthode qui se chargera directement de stocker cette chaine dans le tableau interne.
Résultats
| Avant | Après | |||
|---|---|---|---|---|
| Self. | Called | Self. | Called | |
| addCacheID | 5,99 | 1200 | 3,84 | 600 |
| addRawCacheID | 0 | 0 | 0.06 | 600 |
| Total | 5,99 | 1200 | 3,90 | 1200 |
Soit un gain de 2,09. Bien sûr, cela n'est pas suffisant, il faut réitérer la technique n°1. Et cette fois-ci, on remarque la méthode loadParamaters.
Comme la méthode précédente, elle consomme beaucoup, sans être relativement beaucoup appelée.
Contrairement au cas précédent, cette méthode est appelée à bon escient. C'est donc son code interne qui est mauvais. Il faut donc la réécrire différemment.
Résultats
| Avant | Après |
|---|---|
| 9,30 | 2,41 |
Soit un gain de 6,89. Et on peut continuer comme cela autant de fois que l'on souhaite...
Conclusion
Xdebug est un bon outil pour ceux qui souhaitent améliorer finement leur code PHP. Par contre, si le but ultime de l'optimisation est l'amélioration des performances d'une application PHP alors avant d'utiliser Xdebug, il convient de regarder ailleurs. Car si Xdebug permet d'optimiser son code PHP, les gains obtenus sont dans la plupart des cas minimes et ils ne règleront probablement pas les gros problèmes de lenteur.
