Nous avons été assez déçus par le changement de moteur de base de donnée.
La nouvelle base est bien plus robuste, mais nous attendions de meilleures performances.
En fait les gains ont été assez minimes, de l'ordre de 20 %.

Aussi pendant l'été nous avons cherché à optimiser dans les moindres détails le code du CMS.
Mais les améliorations n'ont influé que faiblement sur les résultats en production. Jusqu'à ce qu'on se rende compte que notre architecture de test au CampusPlex se comportait parfois de manière très différente par rapport à la prod.

En analysant les différences entre les achitectures de développement et de production, nous avons découvert le pot aux roses. L'application n'est pas en cause. Le problème, c'est une incompatibilité au sein de l'architecture d'hébergement WM.
Après une folle semaine de bench nous avons identifié le coupable, le système de virtualisation Xen bridait nos serveurs de base de donnée pSQL à 50% de leur capacité.

Aussi depuis 10 jours nous testons une toute nouvelle architecture logicielle sur 10% des sites. Elle est stable et procure de bien meilleurs résultats. Nous allons généraliser ce système d'ici la fin Octobre.

C'est bien connu, une bonne nouvelle n'arrive jamais seule .... Je dis cela car face à l'incertitude dans laquelle nous étions plongé, croyant manquer de puissance, nous avons passé commande de nouveaux serveurs et surtout d'un nouveau serveur de fichier.
Il a la particularité d'être full SSD, il est composé de 24 disque 600 Go à mémoire flash 100 fois plus rapide que des disques classiques et infiniment moins consommateur d'énergie.

Ce système de stockage va contenir toutes les données fraiches, et sera épaulé par le NAS de 48 disques de 2To.

Possédant désormais de plus grandes capacités, servies par un système ultra-rapide, voilà la deuxième bonne nouvelle :

On augmente les espaces disques !! chez tout le monde :
- Portail Primo passe de 25 à 30 Go
- Portail Xpert passe de 50 à 60 Go
- Portail Pro passe de 150 à 180 Go
- WebTV Primo passe de 50 à 60 Go
- WebTV Xpert passe de 150 à 180 Go
- WebTV Pro passe de 500 à 600 Go

Du coup les capacités des emails aussi :)
-Small passe de 50 à 500 Mo
-Medium passe de 250 Mo à 1Go
-Large passe de 500 Mo à 1.5Go

Et comme il y a plus de place les uplaod vidéos changent aussi pour le CMS:
- Portail Primo passe de 150 à 250 Mo
- Portail Xpert passe de 500 à 600 Mo
- Portail Pro passe de 700 à 800 Mo

Nous avons changé ce matin tôt le système de base de donnée utilisé par WMaker depuis 2001. C'est une modification très lourde que nous préparons depuis 1 mois et demi. La conversion de la base de donnée a pris 8 heures.

 

Le service n'a connu aucune interruption pendant ce changement pour vos visiteurs. Nous avons seulement du couper l'accès au back office pour ne pas désynchroniser l'ancienne base avec la nouvelle.

 

 

C'est un tour de force qu'a réalisé Grégory, c'est un peu comme changer le moteur d'une voiture tout en continuant à rouler. Mais ce matin à 6 h 00 heureusement que toute l'équipe de mécaniciens était sur le pont.

 

Nous avons corrigé les plus gros bug dès midi. Le support technique a chauffé toute la journée, nous avons reçu beaucoup de messages. Une partie de l'équipe est toujours en train d'apporter des correctifs à l'heure où j'écris cette note.

 

Nous somme assez fatigués en cette fin de journée, mais plutôt satisfaits du travail accompli. Cela va nous permettre de grossir tout en améliorant la rapidité des sites WMaker. 

 

Il y a un mois, nous avions recréé une mini-architecture WMaker au CampusPlex. Tous vos sites tournaient sous PostgresSQL en test interne. Une équipe de 10 bêta-testeurs a trituré les clones de vos sites pendant 2 semaines afin de dresser la liste des bugs pour l'équipe de développement avant la mise en production.

 

Nous pensons après cette longue journée, qu'il reste une journée de travail pour régler l'ensemble des petits soucis. A partir de la semaine prochaine nous allons pouvoir utiliser tout le potentiel de ce nouveau moteur et gagner en temps de réponse. 

Comme annoncé précédemment, nous allons changer de moteur de base de données dans la nuit. Nous profitons des grandes vacances pour faire cette manipulation sur laquelle nous travaillons depuis des mois.

Pendant cette bascule qui va durer une bonne partie de la nuit, nous allons fermer les backoffice de tous les sites. Les sites restants bien évidement actifs pendant la durée de la bascule.

Nous avons mis en place 2 équipes pour se répartir le travail afin d'être le plus réactif possible. En effet, nous prévoyons de nombreux ajustements demain toute la journée. La 1erè équipe va travailler cette nuit, la seconde arrive à 6 heures du matin pour prendre le relai.

Début des opérations 20h00 (GMT+2), vous pourrez nous suivre sur Twitter,

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.

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 !

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.

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 ......

WMaker possède plus d'une centaine de serveurs physiques et virtuels. On compte plus de 160 disques durs. Les OS utilisés sont Linux et Solaris.

Les serveurs sont des machines qui exécutent une tache spécifique (base de données, page web, mails, etc...)

Les différents serveurs de l'architecture sont les serveurs :

- Web : ils fournissent les pages qui s'affichent sur votre navigateur
- back : ils fournissent spécifiquement les pages de vos backoffice.
- SQL : ils fournissent le contenu des pages stockés en base de données (MySQL et PostgreSQL)
- Mail : ils gèrent les envois et réception des mails
- Vidéos : ils gèrent le streaming, l'encodage et le stockage des vidéos
- Reverse Proxy : ils gèrent la circulation de toutes les données entre les serveurs, ce sont eux qui reçoivent votre demande et sollicitent les autres serveurs, enfin ils vous renvoient le tout.
- De cache : ils stockent une copie des pages ou partie des pages demandées afin de les fournir ultérieurement pour une plus grande rapidité.
- De Stats : ils calculent et fournissent quotidiennement les stats.
- De fichiers : ils fournissent les scripts nécessaires au fonctionnement des sites (Php, Python, etc...), mais aussi des images, des documents en téléchargement, vidéo ou même des mails.
- De taches : ils effectuent des taches quotidiennes, génération des vignettes, encodage, calculs

Toutes les données contenues sur l'ensemble des sites sont sauvegardées en permanence vers 2 autres sites.

Les serveurs sont monitorés en permanences par 3 systèmes :

- un système interne qui alerte plusieurs personnes par mail en cas de problème
- système externe géré par WMaker, Nagios, qui surveille et prévient en cas de problème
- une société tierce qui surveille aussi l'architecture.

Sur une telle architecture, les problèmes arrivent, ce sont donc les serveurs Reverse Proxy qui aiguillent alors vers les serveurs redondants.
De notre côté une fois alertés nous relançons le serveur qui pose problème et si nous sommes devant une panne physique (disque dur qui lâche par exemple) nous nous rendons sur place changer le disque défectueux.
De plus les serveurs sont redondés, c'est à dire que si un serveur tombe en panne ou s'arrête, un autre prend le relais automatiquement afin de ne pas couper le service et nous permet d'intervenir.

Quand vous entrez cette adresse dans votre navigateur, les serveur DNS vous renvoient vers notre architecture.
La un serveur Reverse Proxy prend en charge votre demande, il demande alors au serveur Web la structure de la page, au serveur SQL le contenu, au serveur Static toutes les images et les feuilles CSS, au serveur vidéo les vidéos.
Mais il vérifie aussi qu'une telle page n'a pas déjà été créée et disponible sur un serveur de cache, auquel cas il la récupère (plus rapide). Enfin il vous renvoie la page ainsi constituée.

Des ralentissements d'affichage sont probables, il est possible qu'il y ait du retard dans l'expédition des newsletters, et le calcul de stats ne sera lancé que dans l'après-midi.

Mise à jour de la note :

Greg, Jérôme et Samir vont travailler encore cette nuit dans le data center. Cette fois il n'y a pas de coupure à prévoir, mais une instabilité est possible.

Ils vont remplacer les processeurs des 8 dernières machines ne disposant pas de processeur à économie d'énergie. Nous remplaçons les Opterons dualcore 2,6 Ghz par des processeurs quadcore.

Ces nouveaux processeurs, outre le fait qu'ils disposent de 4 unités de calcul à la place de 2, consomment nettement moins d'énergie. Nous allons gagner 50 W par serveur, soit une économie de 400 W au total.

L'ensemble de notre architecture est virtualisée depuis 2 ans, c'est à dire qu'une machine physique est découpée en plusieurs machines virtuelles afin d'exploiter au maximum les ressources matérielles. Ainsi, nous pouvons garantir un rapport Page Servies / Consommation électrique très supérieur aux solutions d'hébergement classiques.

Nous allons travailler d'ici la fin de l'année à vous fournir un tableau de bord du Cloud WMaker, intégrant des indicateurs de performance environnementale.

Depuis la fin mai, vous disposez d'un tableau de bord pour suivre vos statistiques. Ce tableau de bord sert de point d'entrée pour la consultation des pages détaillées des stats.

Il existe une nouvelle page dont je ne vous ai pas encore parlé, la page indiquant la consommation détaillée de votre bande passante. Son utilisation est liée aux annonces fracassantes qui ont eu lieu ces derniers jours :augmentation des capacités d'hébergement et diffusion des vidéos en HD.

Cette nouvelle page de statistiques permet d'identifier les éléments de votre site qui participent le plus à la consommation de votre quota mensuel de bande passante.

Cette page est astucieuse. Elle s'affiche uniquement lorsque c'est nécessaire. C'est-à-dire lorsque votre CMS préféré estime qu'il y a un risque que vous dépassiez votre quota mensuel de données transférées.

Lorsque c'est le cas, la bande passante s'affiche en rouge dans le tableau de bord. Un clic sur le chiffre rouge permet d'accéder à cette "page cachée".

La page est divisée en 2 grande sections. En partie haute, nous vous donnons des indications pour vous permettre d'optimiser vos pages afin qu'elles consomment moins de BP.

Par exemple, si votre page d'accueil contient beaucoup de modules, le système vous l'indique. Vous êtes informé également du type de contenu qui consomme le plus de bande passante sur votre site. Dans la capture d'écran ci-dessus, il s'agit des vidéos (flv).

En partie basse, vous avez le détail de la consommation par éléments. Dans la capture d'écran ci-contre, on peut noter que les vidéos flv (c'est à dire lues directement sur votre site) comptent pour 62Go de consommation.

Ensuite, ce sont les images jpg et png qui consomment le quota.

Enfin, on peut dire que pour ce site, il existent des utilisateurs qui consultent les vidéos depuis un mobile, flux rss ou iTunes. En effet, avec ces support, c'est le format mp4 qui est utilisé pour les vidéos.

Voilà, avec cette page, il vous sera très facile d'anticiper ou bien d'identifier les causes du dépassement de votre quota de bande passante. Vous pourrez alors agir efficacement.