Le passage à la V5 nous a donné du fil à retordre, rien n'a voir avec la V5 en elle-même, mais l'architecture serveur qui la supporte rencontre des fluctuations de performance.
Lors de la Bêta, nous avons du mettre à jour certains serveurs car pour fonctionner correctement, la V5 nécessitait la dernière version de PHP et de Debian. Tout a bien fonctionné pendant la phase de test, si bien qu'au lancement de la V5, nous avons basculé l'ensemble des serveurs web dans cette configuration.
Lors de la Bêta, nous avons du mettre à jour certains serveurs car pour fonctionner correctement, la V5 nécessitait la dernière version de PHP et de Debian. Tout a bien fonctionné pendant la phase de test, si bien qu'au lancement de la V5, nous avons basculé l'ensemble des serveurs web dans cette configuration.
La persévérance finit toujours par payer
A partir ce moment là, par moment, nous avons enregistré des temps de réponse anormaux. On aurait pu faire marche arrière au prix de quelques modifs dans la V5 mais l'équipe était assez partagée sur les causes du ralentissement. De plus, les graphs laissaient planer un doute sur l'origine du problème.
Aussi nous avons décidé d'intervenir à 2 niveaux :
1/ directement sur l'architecture pour régler le problème à court terme, mais les administrateurs avaient beaucoup de mal à stabiliser les performances.
2/ au niveau du code de l'application en affectant la totalité de l'équipe de développement à la recherche des voies d'optimisation supplémentaires pour la V5.
Pour contrecarré ces problèmes de performances, des dizaines de modifications ont été effectuées. Je ne vous cache pas que c'était assez tendu voire même usant. Certaines modifications nous ont demandé plusieurs jours de travail et se sont révélées très décevantes en terme de gain.
Cette baisse de performance nous omnubilait. On pensait à rien d'autre du matin en se levant jusqu'au soir en se couchant. D'habitude, chacun travaille sur son poste avec une répartition des tâches assez naturelle mais cette fois-ci, il a fallu repenser l'organisation des équipes pour mettre toutes les chances de notre coté. Les développeurs se sont regroupés en binômes et parfois plus pour être mieux armés face à ce problème dont la cause était difficile à identifier.
Nous avons testé plein de nouvelles choses et remis en cause des choix qui nous semblaient acquis... et au final, nous avons réussi !
Les itérations successives nous ont permis de gagner de manière significative sur les temps de réponses. Ce qui nous a ramené à la normale !
Aussi nous avons décidé d'intervenir à 2 niveaux :
1/ directement sur l'architecture pour régler le problème à court terme, mais les administrateurs avaient beaucoup de mal à stabiliser les performances.
2/ au niveau du code de l'application en affectant la totalité de l'équipe de développement à la recherche des voies d'optimisation supplémentaires pour la V5.
Pour contrecarré ces problèmes de performances, des dizaines de modifications ont été effectuées. Je ne vous cache pas que c'était assez tendu voire même usant. Certaines modifications nous ont demandé plusieurs jours de travail et se sont révélées très décevantes en terme de gain.
Cette baisse de performance nous omnubilait. On pensait à rien d'autre du matin en se levant jusqu'au soir en se couchant. D'habitude, chacun travaille sur son poste avec une répartition des tâches assez naturelle mais cette fois-ci, il a fallu repenser l'organisation des équipes pour mettre toutes les chances de notre coté. Les développeurs se sont regroupés en binômes et parfois plus pour être mieux armés face à ce problème dont la cause était difficile à identifier.
Nous avons testé plein de nouvelles choses et remis en cause des choix qui nous semblaient acquis... et au final, nous avons réussi !
Les itérations successives nous ont permis de gagner de manière significative sur les temps de réponses. Ce qui nous a ramené à la normale !
Dépasser les limites
Tout cela nous a pris environ un mois mais nous avons quand même décidé de poursuivre encore nos efforts. Nous devons aller au bout de ce qu'il convient de faire pour garantir les meilleurs performances pour la V5. L'équilibre actuel ne nous satisfait pas à moyen terme.
Aussi nous avons mis sur pied un plan de bataille pour atteindre des performances top niveau et surtout les garder. En effet, au cours de nos investigations, une découverte nous fait penser qu'il y a encore une marge d'optimisation très significative à obtenir. Si on analyse les graphs attentivement, on remarque qu'il y a peu d'écart entre le temps moyen et le temps minimum d'exécution d'une requette. Cela veut dire que peu importe le nombre de visiteurs sur les serveurs, nous n'arrivons pas à descendre sous un certain plancher.
Pour franchir ce plancher, nous allons travailler sur chaque étage de l'architecture de WMaker en optimisation chacun des 6 niveaux. En effet, nous avons la chance de pouvoir optimiser à la fois la partie logicielle, car nous maitrisons totalement le code source de WMaker, et également la partie hardware, sur laquelle tourne WMaker. Ceci nous permet d'avoir un temps d'avance sur ce que proposent les hébergeurs.
Aussi nous avons mis sur pied un plan de bataille pour atteindre des performances top niveau et surtout les garder. En effet, au cours de nos investigations, une découverte nous fait penser qu'il y a encore une marge d'optimisation très significative à obtenir. Si on analyse les graphs attentivement, on remarque qu'il y a peu d'écart entre le temps moyen et le temps minimum d'exécution d'une requette. Cela veut dire que peu importe le nombre de visiteurs sur les serveurs, nous n'arrivons pas à descendre sous un certain plancher.
Pour franchir ce plancher, nous allons travailler sur chaque étage de l'architecture de WMaker en optimisation chacun des 6 niveaux. En effet, nous avons la chance de pouvoir optimiser à la fois la partie logicielle, car nous maitrisons totalement le code source de WMaker, et également la partie hardware, sur laquelle tourne WMaker. Ceci nous permet d'avoir un temps d'avance sur ce que proposent les hébergeurs.
De MySQL à PosgtreSQL
Nous avons la conviction que nous n'arriverons pas optimiser de manière significative WMaker sans changer le moteur de base de donnée.
Nous avons donc décidé de remplacer MySQL par PostgreSQL.
MySQL est un très bon système de base de donnée, il est très simple et tient bien la charge, mais ses performances se dégradent quand le volume de données augmente.
C'est la raison pour laquelle, il y a 2 ans, en prévision de l'atteinte des limites de MySQL, nous avions déployé le Wrapper SQL. Le Wrapper SQL créé une couche d'abstration sur la BDD afin que WMaker puisse fonctionner sur n'importe quel système de base de données. Nous sommes en train de valider que l'ensemble des requettes du Wapper SQL sont bien compatibles avec la syntaxe PostgreSQL.
J'aurais du communiquer au fil de l'eau mais franchement j'étais dans le flou et j'ai préféré attendre de disposer d'un plan de bataille avant de m'exprimer. Le voici :
4 au 13 Juillet : test sur l'environnement de développement de PostgreSQL
9 et 10 Juillet : installation des nouveaux serveurs HP
18 Juillet : bascule de WMaker sur PostgreSQL
18 au 31 : suivi de la migration.
Du coup, nous avons fait le choix de reporter certaines nouvelles fonctionnalités à la rentrée de septembre afin de régler de manière approfondie nos soucis de croissances ...mais aussi de prendre nos vacances l'esprit léger ......
Nous avons donc décidé de remplacer MySQL par PostgreSQL.
MySQL est un très bon système de base de donnée, il est très simple et tient bien la charge, mais ses performances se dégradent quand le volume de données augmente.
C'est la raison pour laquelle, il y a 2 ans, en prévision de l'atteinte des limites de MySQL, nous avions déployé le Wrapper SQL. Le Wrapper SQL créé une couche d'abstration sur la BDD afin que WMaker puisse fonctionner sur n'importe quel système de base de données. Nous sommes en train de valider que l'ensemble des requettes du Wapper SQL sont bien compatibles avec la syntaxe PostgreSQL.
J'aurais du communiquer au fil de l'eau mais franchement j'étais dans le flou et j'ai préféré attendre de disposer d'un plan de bataille avant de m'exprimer. Le voici :
4 au 13 Juillet : test sur l'environnement de développement de PostgreSQL
9 et 10 Juillet : installation des nouveaux serveurs HP
18 Juillet : bascule de WMaker sur PostgreSQL
18 au 31 : suivi de la migration.
Du coup, nous avons fait le choix de reporter certaines nouvelles fonctionnalités à la rentrée de septembre afin de régler de manière approfondie nos soucis de croissances ...mais aussi de prendre nos vacances l'esprit léger ......