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 !
11 réactions
1 De desfrenes - 09/10/2012, 22:08
Ahaha, ce teasing de fou...
Solution e-commerce spécifique ou du marché ? Si oui, open source ou pas ? Si oui, française ? ^^
2 De Jean-François - 10/10/2012, 10:00
Le début d'un bon roman à suspense !
Y'a pas un client torrent camouflé sur le serveur qui tourne en toile de fond ?
Plus sérieusement, une petite question : la baisse des performances s'est manifestée où ? Dans l'exécution des applicatifs ? Pour le client (HTTP) ? ...
3 De mageekguy - 10/10/2012, 10:14
@desfrenes : Solution home-made car sur un créneau hyper spécifique, avec des règles métiers particulières.
4 De mnapoli - 10/10/2012, 13:25
Mais curiosité me pousse : le front-office e-commerce a commencé à ralentir uniquement lorsque le site d'administration a été migré ?
5 De mageekguy - 10/10/2012, 13:32
@mnapoli : Lorsque les deux sites ont été mis à jour.
6 De pluriels - 10/10/2012, 13:52
Je mise sur un goulet d'étranglement réseau !
Interface réseau mal configurée ?
7 De raphael - 10/10/2012, 14:06
@pluriels "dans le cas de notre client, le tout est stocké sur une seule et même machine" donc je doute que le réseau intervienne ?
8 De pluriels - 10/10/2012, 14:50
Je cherchais quelque chose de tordu, dans un environnement virtualisé, j'avais rencontré de gros problèmes sur l'interface réseau en raison du bridge IP.
top -> aucune anomalie criante (CPU / RAM) mais beaucoup d'attente pour le réseau
Si la bdd n'est pas en cause, je m'orienterai volontiers vers le hard / OS.
Après, j'essaie de brouiller les pistes
9 De Geekbay - 10/10/2012, 19:07
Moi je sens que c'est quelques choses d'autres, l'utilisation d'un javascript qui ralentit l'utilisation du site, genre un plugin jquery qui rend les forms plus beau ou un script js qui prend trop de tps a chercher dans le DOM et donc la page met trop de tps a s'afficher et ce n'est pas lié ni à PHP ni à mysql.
Je suis sur la voie?
10 De desfrenes - 10/10/2012, 23:04
@mageekguy : je suis déçu, on va pas pouvoir troller sur magento ou prestashop
11 De cydelic - 10/10/2012, 23:27
Perso je pencherai plus sur un problème reseaux/conf système qui impacterai les appels SOAP
Après tu nous a pas parler des logs d'erreur, apache ? php ? mysql ? system ? C'est generalement la 1ere chose à regarder.
J'attends la suite avec curiosité