En fait, j'étais sur la bonne piste dès le départ, puisque je soupçonnais quasi depuis le début de mes investigations un problème d'accès concurrent à une ressource spécifique puisque les requêtes HTTP asynchrones entre le site d'administration et la boutique électronique étaient traitées de manière séquentielle et non parallèlement.

J'avais tout d'abord incriminé la session PHP et j'avais donc écris au niveau du site d'administration un gestionnaire de gestion spécifique qui ne faisait strictement rien, mais sans que cela ait pour autant résolu le problème.

Et pour cause, puisque si l'explication était bien la bonne, je ne l'avais pas appliqué sur le bon site et de plus, j'avais complètement oublié que PHP pose un verrou sur la ressource correspondant à une session de lui-même indépendamment du gestionnaire de sessions utilisées.

Un petit détour par Google pour faire une recherche avec les mots-clefs php ajax session lock n'a fait que confirmer mon intuition puisqu'elle m'a permis d'avoir la confirmation du fait qu'afin d'éviter des accès concurrents susceptible de la corrompre, PHP verrouille une session dès qu'elle est ouverte sur le serveur et ne retire son verrou qu'une fois qu'elle a été refermée.

Or, comme les requêtes asynchrones entre mon navigateur et les deux sites concernés démarrait systématiquement une session via la directive session.auto_start, la première requête traitée par le serveur s'appropriait la session qui devenait alors indisponibles pour les autres, qui devaient donc attendre qu'elle soit libérée, d'où le traitement séquentielle que j'avais constaté.

Du coup, après avoir édité les fichiers adéquates pour y ajouter un appel à la fonction session_write_close() (certain parmi mes lecteurs avait trouvé l'origine du problème dès le premier épisode et je me suis permis de censurer leurs commentaires afin de ménager le suspense, j'espère qu'ils ne m'en tiendront pas rigueur), j'ai eu la joie de constater que mes requêtes HTTP asynchrones étaient maintenant bien exécutées parallèlement par le serveur, à la fois entre mon navigateur et la boutique électronique et entre la boutique électronique et le site d'administration.

Et du coup, les performances ont été d'un coup très nettement améliorées, d'autant que mon équipe avait effectuées en parallèle d'autres optimisations tant au niveau du site d'administration que de la boutique électroniquen notamment en réduisant fortement le nombre de requêtes asynchrones nécessaires aux différents traitements requis par le métier.

Après avoir terminé le nettoyage, nous avons donc la version corrigé du code des deux sites en production, et j'ai alors serré un peu les fesses.

En effet, là ou auparavant, le serveur traitait les unes après les autres des requêtes asynchrones relativement gourmandes en terme de ressources, il allait maintenant devoir dorénavant les exécuter simultanément, ce qui pouvait lui poser un certain nombre de problème en terme de ressources consommées.

En effet, si nous avions bien effectué manuellement quelques tests de montée en charge sur les versions de pré-production et que la machine avait non seulement tenue le choc mais également répondu en moyenne trois à quatre fois plus vite que précédemment , seule la (dure) réalité d'un environnement de production permet effectivement de valider une solution technique et j'avais donc quelques appréhensions lorsque nous avons effectué une nouvelle fois la montée en version.

Cependant, pour mon plus grand plaisir, les graphiques fournis par notre supervision n'ont pas montré de hausse significative de la charge du serveur à court terme et encore moins sur le long terme.

Il ne me restait donc plus que deux choses à faire, à savoir comprendre pourquoi nous n'avions jamais décelé ce problème auparavant, et surtout tirer les leçons de ce triste épisode afin de ne pas refaire les mêmes erreurs.

Nous avons assez vite compris pourquoi nous n'avions jamais rencontré de problèmes jusque là.

En effet, parmi tout nos clients, celui concerné par cette difficile montée en version est celui qui dispose des bases de données les plus volumineuses, cele de la boutique électronique contenant les données correspondant à plus de deux ans d'exploitation tandis que celle du site d'administration contient des informations remontant jusqu'à 2008.

Nos autres clients disposant de bases de données beaucoup moins volumineuses, la dégradation des performances induites par la mauvaise gestion des sessions PHP n'était donc pas très perceptible, ou du moins, elle n'avait pas été jugée suffisante par notre hiérarchie pour justifier l'arrêt des développements en court le temps d'effectuer l'audit nécessaire pour améliorer la situation.

Et comme de plus, notre client utilisait jusqu'à maintenant une version qui ne souffrait pas de ce défaut de conception, nous n'avons eu malheureusement aucun moyen d'anticiper le problème.

À contrario, l'autocritique que j'ai effectué sur la façon dont j'ai mené cet audit technique a été un peu plus difficile, car beaucoup de facteurs sont entrés en jeu et ont influencé fortement la façon dont je l'ai mené.

Mais je vous en parlerai plus en détail dans le cinquième et dernier épisode !