Lors de mon retour au bureau le lendemain matin, j'ai donc retrouvé mon équipe en plein brainstorming sur le sujet, et j'ai donc écouté en silence la discussion pour ne pas les couper dans leur élan.

Cependant, je suis arrivé très rapidement à la conclusion qu'ils étaient tout autant dans le brouillard que moi.

Ils ont alors proposé de repartir de la version précédente du serveur d'administration, qui joue également le rôle de serveur SOAP, et d'y introduire progressivement chacune des modifications nécessaires pour parvenir à la version finale, afin d'identifier le code responsable de la dégradation des performances.

J'avoue ne pas avoir été du tout convaincu par la stratégie proposée, car par expérience, je sais qu'il est quasiment impossible d'obtenir un résultat concret de cette façon, d'autant que dans notre cas, le nombre de modifications était important et que le problème pouvait provenir d'une interaction entre plusieurs d'entre elles.

Pour autant, je les ai laissé faire, car après tout, les miracles existent à ce qu'il paraît, et je suis parti sur une stratégie toute différente.

Arrivé à ce point, il est important de préciser qu'à première vue, le responsable de la baisse des performances était le serveur SOAP encapsulé au sein du serveur d'administration, car les requêtes AJAX qui y faisaient appel duraient bien trop longtemps, voir dans le pire des cas se terminaient en time-out.

L'utilisation des commandes top et iotop ainsi qu'une vérification des fichiers de configurations relatifs à la couche réseau du système ainsi qu'à PHP et apache m'ayant confirmé que tout allait bien de ce côté, il était donc logique que je concentre mes efforts sur le serveur SOAP.

De plus, outre le fait que c'était apparemment ce dernier qui semblait ralentir la solution, il a également une très mauvaise réputation auprès du développeur du site de e-commerce qui l'accuse régulièrement d'être très lent et de pénaliser fortement les performances du site de e-commerce.

J'ai donc dégainé XHProf et XHGui, et après les avoir installés, configurés et demandé au développeur du site de e-commerce d'injecter dans les URL des services SOAP la variable adéquate, j'ai commencé à obtenir des statistiques sur le comportement du script PHP correspondant au serveur SOAP.

Cependant, si j'ai été très impressionné par le nombre d'appels de fonctions et par la quantité de mémoire vive consommée par les scripts, deux signes me confirmant qu'il y avait effectivement de l'optimisation et du nettoyage à faire, encore une fois, je n'ai rien trouvé de réellement significatif à ce niveau.

Et entre parenthèses, j'ai eu au passage la confirmation que l'utilisation de SOAP n'était pas le protocole le plus pratique dans ce contexte, car le service appelé étant encodé dans le corps de la requête HTTP et non dans l'URL , il est impossible de faire correspondre une statistique avec un appel de service précis.

Malgré l'absence de signe significatif permettant de localiser la ou les fonctions phagocitant les ressources du serveur, j'ai tout de même analysé plus en profondeur les appels les plus gourmands, notamment parce qu'à ce point, je ne voyais pas bien quoi faire d'autre.

Mon analyse m'a finalement amené à modifier une fonction de bas niveau de façon à ce qu'elle ne soit plus récursive (d'ailleurs, cela fera l'objet d'un prochain billet) mais mon optimisation n'a finalement pas fait de réelle différence au niveau des performances globales.

j'étais donc plus que désappointé en fin de journée, d'autant que comme je l'avais anticipé, le reste de l'équipe n'avait pas rencontré plus de succès que moi dans la recherche du problème.

J'ai donc laissé tomber le profilage du site d'administration, et j'ai commencé à regardé un peu plus attentivement ce qu'il se passait au niveau des requêtes AJAX sur le site de e-commerce à l'aide de Firebug.

Et à ma grande surprise, j'ai découvert que les requêtes en question ne semblaient pas être traitées parallèlement par le serveur HTTP, mais les unes derrière les autres.

Le site de e-commerce utilisant jQuery, un rapide grep sur ses fichiers javascript m'a confirmé que les appels étaient réalisés correctement et surtout que la variable async n'était jamais utilisé pour forcer l'envoie séquentiel des requêtes AJAX.

L'origine du problème devait donc forcément provenir de la pose d'un verrou exclusif par un script PHP sur une ressource partagée par l'ensemble des scripts PHP !

C'est donc un peu plus confiant en l'avenir que la veille que j'ai quitté le bureau, car j'avais enfin une piste de réflexion tangible à suivre et une idée pour résoudre le problème.

À ce moment, je n'aurais donc jamais pu imaginer combien j'étais à la fois très proche et très éloigné de la solution, et je vous dirais pourquoi dans le prochain épisode !