Avant de commencer, pour la bonne compréhension de ce qui va suivre, je suis obligé de vous donner certain détail technique concernant l'architecture de la solution concernée.

Elle est principalement composée d'un site de e-commerce qui dialogue avec un site d'administration via des services SOAP, et dans le cas de notre client, le tout est stocké sur une seule et même machine, sur des disques SSD, et propulsé par un processeur i5 alimenté par 16 Go de RAM exécutant un PHP 5.3.x un MySQL 5.5.x, l'ensemble étant coordonné par une distribution Linux Debian.

Chaque site dispose de sa propre base de données, mais le dialogue entre la base de données du site d'administration et le site de e-commerce se fait exclusivement via les services SOAP.

Durant la montée en version en question, le site e-commerce a été mis à jour avec une version déjà en production pour d'autres clients sans qu'aucun problème de performance n'ait été constaté à aucun moment.

Le site d'administration a été quand à lui mis à jour avec une version totalement nouvelle mais ne présentant pas de rupture réellement significative avec la version précédente, l'essentiel des modifications étant des corrections de bugs et des ajouts de fonctionnalités nécessaires à d'autres clients.

Pour autant, la bonne adéquation des deux sites avait tout de même été vérifiée en pré-production, et personne n'avait rapporté le moindre problème.

J'ai donc été relativement surpris de la baisse des performances observée par notre client, même s'il était absolument indéniable, et nous avons donc commencé, mon administrateur système, le développeur du site e-commerce et moi-même, à en chercher l'origine.

La seule différence notable entre le site de e-commerce déjà en production précédemment chez un autre client et présentant des performances correctes et celui que nous venions de mettre en production était la taille de la base de données.

Notre client du jour dispose en effet d'une base de données beaucoup plus importante, et c'est donc assez naturellement (et également très bêtement rétrospectivement) que nos soupçons se sont portés en premier.

Nous nous sommes donc connecté sur le serveur et nous avons commencé par faire appel à la commande top, ce qui nous a permit de constater, à notre grand étonnement, que le serveur ne présentait pas une charge globale très élevée mais au contraire plutôt raisonnable.

Nous avons donc supposé que le goulet d'étranglement était situé au cœur de MySQL, mais après nous être connectés au serveur de base de données armé de l'excellent livre Audit et optimisation MySQL 5 et avoir effectués les contrôles ad hoc, nous n'avons rien trouvé de réellement significatif à ce niveau. Il y avait bien quelques ajustements à faire, mais rien de suffisamment significatif pour entraîner une augmentation des performances, et un appel à mysqltuner nous l'a par ailleurs confirmé.

Entre temps, la décision avait été prise par le reste de l'équipe, en collaboration avec le client, de revenir à la version précédente à la fois du site de e-commerce et du site d'administration.

Une tentative de marier la nouvelle version du site de e-commerce avec l'ancienne version du site d'administration a même été effectuée avec succès, mais n'a pas apporté de changement significatifs aux performances de la solution, qui sont restées toutes aussi mauvaises.

C'est donc avec les versions précédentes du site de e-commerce et du site d'administration en production afin de permettre au client d'assurer son chiffre d'affaire et la tête remplie de questions sans réponse que j'ai quitté le bureau le soir venu.

Et si tout comme moi à ce moment, vous avez également la tête remplie d'interrogations et que vous souhaitez en avoir les réponses, je vous invite à lire mon prochain billet sur le sujet !