Nous poursuivons notre politique d'optimisation de l'architecture de l'application WM . Dans ce cadre, une opération de maintenance est prévue dimanche matin. Elle nécessite une interruption de l'accès à l'interface de gestion de votre site.

Coupure des backs offices le matin du dimanche 30 novembre 2008 de 10h00 à 12h00 CET

Le but de la manœuvre est de donner plus de puissance aux serveurs SQL utilisé par les backs offices.

Nous avons poussé beaucoup plus longtemps que prévu notre phase optimisation de l'architecture WMaker.

En fait, 5 personnes ont travaillé pendant un mois sur l'amélioration de la vitesse d'affichage de vos sites et des interfaces administration.

Il y a 1 mois, nous avons eu une hausse très rapide du trafic : + 35 % de pages en plus. Nous n'avions pas prévu une hausse de trafic aussi importante en 2 semaines.

A l'époque, nous avions déjà acheté 8 nouveaux serveurs extrêmement puissants.  Ce sont des Bi-Xeon QuadCore de dernière génération, dotés de 16 Go de Ram et utilisant les meilleurs disques SATA disponibles, les Velocity Raptor de Western Digital.

Toutefois, ce regain de puissance allait être à peine perceptible en raison de cette hausse soudaine de trafic. Nous nous sommes alors donné comme challenge d'optimiser le code de l'application mais nous ne savions pas par où commencer.

Chacun des développeurs de WMaker a dressé une liste des points à améliorer pouvant influencer sur la rapidité d'affichage. 

Nous avons fait du surplace pendant près de 2 semaines. Les progrès étaient modestes et nous étions près à faire auditer notre architecture par des ingénieurs de chez SUN ... cependant, le travail que nous avons mené sur la mise en place d'un Wrapper SQL a fini par porter ses fruits.

En effet, nous travaillons depuis quelques mois sur une couche d'abstraction de la base de donnée. Ce système nous permet entre autre d'avoir un monitoring des 3000 requettes/s effectuées sur les 10 serveurs SQL de WMaker. Nous pouvons alors remonter dans un tableau de contrôle les requêtes les plus fréquentes, les requêtes les plus longues, etc.

Ayant épuisé toutes les pistes pour optimiser le temps de réponse, nous avons alors réécrit, grâce aux informations du tableau de contrôle issus du Wrapper, une dizaine de requêtes SQL par jour pendant 1 semaine et nous avons fait des gains inespérés.

Nous avons alors décidé de poursuivre. Aujourd'hui, au bout de 3 semaines, nous avons non seulement complètement absorbé la hausse trafic, mais nous avons amélioré le temps de réponse d'un facteur 3  !!!!!

Grace à ce travail, nous sommes maintenant probablement l'une des plate-forme SaaS de site internet la plus rapide du marché.

Nous allons jusqu'à à la fin janvier consacrer un jour par semaine à ce genre d'optimisation. Nous avons pour objectif d'atteindre un temps de réponse moyen 250 ms.

Après ce mois d'optimisation, nous allons reprendre la publication des nouveautés, d'ici la fin novembre nous retrouverons notre rythme de croisière.

Dès demain on revisite les TAGs !!

Aujourd'hui Jerome et Greg travaillent dans le datacenter DC1 à l'évolution de l'architecture.

Il s'agit d'un datacenter de nouvelle génération conçu par la société OVH.  Il a la particularité de consommer 30 % d'énergie en moins par rapport à un datacenter classique.

Ils sont en train d'installer une dizaine de tous nouveaux serveurs SUN X2250. Ce sont des serveurs basse consommation. Les processeurs ne consomment que 50 W  alors que la génération précédente flirtaient avec les 95 W.

Nous avons également choisi des disques durs économes après avoir testé des disques à mémoire flash SSD qui ne se sont pas révélés très concluants au final ... Nous avons donc opté pour des disques plus classiques, ce sont des Velocity Raptor. Ils nous permettent d'économiser quelques Watts par serveur par rapport aux anciens disques Raptor que nous utilisions précédemment.

Partout ou nous pouvons, nous faisons le choix de matériel base consommation. En ces temps de crise financière on ne veut pas mettre entre parenthèse l'écologie, on garde le cap ;-) Il s'agit également d'un choix économique car en optimisant notre consommation nous pouvons installer plus de serveur dans une baie. Quand les choix économiques rejoignent les choix écologiques il n'y a pas à hésiter, on fonce ...

La consomation des serveurs n'est pas la seule variable sur laquelle nous pouvons agir, la partie logiciel est tout aussi capitale.

Nous avons pour cela virtualisé l'ensemble de l'architecture. Cela nous permet d'augmenter le rendement par machine.

Au niveau de l'application WMaker, nous avons entrepri depuis 2 semaines une phase d'optimisation. Nous en parlions déjà la semaine dernière dans le blog Tech. Nous attendons comme effet une augmentation de la vitesse d'affichage de vos sites et une augmentation du rendement électrique.

D'ici la fin de l'année, notre architecture sera 100 % basse consommation.