Résumé des épisodes précédents

- Janvier 2008 : Sun achète Mysql pour 1 Milliard là où Oracle proposait 750 Millions $
- Avril 2009 : Oracle rachète Sun pour plus de 7 milliards …
- Avril 2009 : Tout le monde flippe pour Mysql

La mariée

Sun c’est une société d’ingénierie vénérable qui a été parmi les premières à créer des serveurs. Chez Sun la conception c’est important, l’ingénierie encore plus et on fait tout à la main avec amour. Résultat, souvent précurseur incompris, Sun n’a pas que des réussites à son actif mais quand même de très belles choses, un parc, un savoir faire et des machines de pointes. Ses propres processeurs Ultraparc et Sparc64, ses architectures, ses bus de données, des milliers de brevets.

Sun c’est aussi du logiciel. Solaris et OpenSolaris pour les operating systems (performants et surtout très robustes), Java pour les langages, la suite openoffice pour le bureau. Mine de rien, déjà, ca pèse un peu lourd tout ca.

Et bien sur……. Mysql.

Mysql ne craint rien !

Mysql est la base de données qui a soutenu le développement de l’opensource. La plus répandue et utilisée au monde. Et Oracle, avant tout le métier d’origine… C’est la base de données. Mais…

Larry Ellison a parfois « acheté pour tuer » mais là, il domine complètement le segment de la base de données. De la TPE au très grand compte. Il peut faire migrer les Mysql vers de l’Oracle quand le compte grossit, faire de la pub sur la clientèle de Mysql, bref…

Pourquoi tuer Mysql ? De toute façon, ceux qui l’utilise n’ont pas le budget pour de l’Oracle.

En plus, tuer un soft opensource c’est très dur. En effet, d’autres feront une autre mouture demain et le pari sera perdu. C’est déjà un peu le cas avec MariaDB et Monty mais ca pourrait empirer si Oracle se montre agressif envers Mysql. Au bout de plus de 6 mois, Mysql existe toujours, il est maintenu, rien n’a réellement changé. Mysql est même sur la Home d’Oracle, déclaration sur la page de Mysql dans le site d’Oracle :

« Oracle will continue to develop and enhance MySQL along with Oracle’s other open source database technologies, Oracle Berkeley DB, the leading open source embedded database, and Oracle InnoDB, the most popular transactional storage engine for MySQL.MySQL customers will benefit from Oracle’s world-class support and training services. MySQL developers and partners will find new opportunities as MySQL becomes a certified part of Oracle’s open, complete, and integrated stack of technology—from application to disk. »

Si Elisson ne tient pas sa promesse, il va se mettre à dos le milieu de l’opensource et se faire détester… Pas très malin et Elisson, il est tout sauf idiot.

Conclusion

La raison de la fusion est (presque) expliquée en homepage du site de Sun et sur celui d’Oracle : « Hardware, Software, complete ». Car Oracle, ce n’est pas que la célèbre database, c’est aussi beaucoup d’autres softs critiques (ceux de peoplesoft par exemple) et de services. La chaine d’Elisson est donc maintenant verticale et horizontale, il a renforcé considérablement sa position.

Personnellement je ne m’inquiète pas pour Mysql mais plus pour IBM ou Microsoft. Larry a souvent protéger son pré carré en mettant dehors des concurrents. Là il possède Java, de quoi sérieusement enquiquiner IBM qui a très largement misé dessus et avec Openoffice, il a de quoi concurrencer Micrososft.

Il est hégémonique sur la base de données et en plus, toujours pour en**rd*r IBM, il a du hardware de qualité, du serveur de combat, un OS qui tient la route….. Alors qui c’est qui mange son chapeau ? C’est Steeve Balmer (Microsoft) et Sam Palmisano (IBM) pardi !

Le grand perdant, ce n’est pas Mysql que son statut de base opensource de référence préserve de toute mort subite ou même moyen terme, c’est IBM à mon sens qui va se faire concurrencer énormément par Oracle sur ses marchés de services. Et pour peu que Larry Elisson se fache sur le segment du soft de bureau, Microsoft va reculer sur Office, son chouchou pendant que Google tente de lui tailler les flancs.

Warning : funny things to come !

PS : Merci à Nicolas.T de Toulouse pour l’idée de ce post

Celle-ci a été annoncée par Varien comme salvatrice pour les performances de notre outil e-commerce préféré (le site annonce un bénéfice de 40% sur le temps de chargement des pages en front office et sur l’utilisation de la mémoire).

Concrètement, que se cache-t-il vraiment derrière cette option « magique » et quel impact aura-t-elle sur les prochains projets construits sur la base de cette version?

Avant toute chose, rappelons que Magento repose actuellement sur un modèle de données de type « EAV » (Entity-Attribute-Value). Ce qu’il faut comprendre c’est qu’un objet « Produit » dans Magento n’est pas stocké dans une seule table mais éclaté dans un ensemble de tables en fonction des attributs de notre produit. Cette complexification du modèle de données se justifie en grande partie par la souplesse que propose Magento dans le paramétrage de nouvelles caractéristiques pour un produit.

Mais cette souplesse a donc un coût puisqu’il multiplie de manière importante le nombre de requêtes effectués en base pour un seul produit. On touche donc très vite aux limites de ce modèle dès lors qu’on travaille avec un catalogue important (plus d’une dizaine de millier de références). Varien a donc annoncé en début d’année qu’ils proposeraient une simplification de ce modèle sous forme d’une option librement activable depuis le back office pour permettre de basculer vers un modèle de données « à plat ».

En regardant de plus près, cette option est un peu plus subtile que ce à quoi on pouvait s’attendre: une fois le mode ‘flat catalog’ activé dans l’administration, on se retrouve finalement avec deux catalogues: un pour le backoffice, et un pour le front:

• celui du backoffice reste le catalogue EAV tel qu’il existe dans la 1.2
• le front utilise des nouvelles tables catalog_category_flat et catalog_product_flat
• il y a une synchronisation type maître-esclave entre le catalogue backoffice et celui du front

Finalement, le « flat catalog » du front est en réalité une sorte de table de cache pour le vrai catalogue qui reste en EAV.

Les avantages de ce fonctionnement:

• la migration est bien plus simple puisqu’en réalité le format de la base n’a pas vraiment changé (les tables _flat sont générées à la demande depuis le backoffice)
• on peut imaginer facilement avoir une base de données front avec les tables _flat côté frontoffice, séparées physiquement de la base de backoffice, avec le moteur Federated de MySQL qui permet de présenter plusieurs bases de données comme en étant une seule aux applications. De ce fait, la charge sur le front n’impacte pas le back et inversement

Les inconvénients:

• avec des volumétries très élevées, (certains) écrans du backoffice vont être très lents puisqu’ils continueront à utiliser le système EAV
• les imports devront continuer à se faire dans les tables EAV, d’où une lenteur au moment de l’import (à nuancer: si les données importées ne sont pas destinées à être utilisées dans le backoffice, il est peut être possible de les importer directement dans les tables _flat du front)

Nos premiers tests sur la base de ce nouveau modèle et d’un catalogue de plus d’un million de produits devraient désormais nous fixer assez rapidement sur la pertinence de cette fonctionnalité…

A suivre donc!

Techniquement c’est des blades et pas des serveurs, mais pour plus de clarté, j’ai ré-éclater ca en serveurs (en plus je n’avais pas les stencils visio pour les blades à l’époque)

On a discuté avec François Ziserman ce matin de l’optimisation de ces charges qui pèsent sur l’infrastructure. Partons du principe qu’on a l’infrastructure qu’on veut, que ce n’est pas un souci de moyen. Que ferions-nous pour aller au plus vite possible en termes de réponse ?

Les soucis principaux dûs à Magento :

• Les frontaux Web consomment énormément de leur temps CPU pour rendre les pages Web
• Les frontaux Web pèsent très peu sur les perfs de la DB
• Le Back Office mange énormément de CPU à la DB lors de ses requêtes et un peu sur son propre CPU

Quelques exemples sur un serveur de production réelle :

Le pic de mardi à 50% est une charge équivalente de 600 à 1000 sessions en gros, cette charge vient uniquement des serveurs Web frontaux, pour ordre d’idée deux personnes qui travaillent sur le backoffice prennent plus de CPU que ces 1000 sessions.

Sur le serveur de backoffice, c’est le calme sur le CPU mais la RAM est très chargée :

Bref bref bref, que faire alors ?

Séparer les écritures des lectures semble une bonne idée.

Si on admet que :

• Les frontends font massivement de la lecture en DB et quelques petites écritures par ci par là pour les données de sessions
• Le backoffice fait beaucoup beaucoup de lectures et des écritures

Comment séparer les unes des autres ?

Avec une base de données master en écriture pour le backoffice et une base de données slave pour les lectures, le problème c’est que le slave ne peut pas faire d’écriture en DB (Alter, Update, Insert, Delete etc…), donc les données de sessions ne sont pas stockées

Le framework Zend (sous jacent à Magento) permet peut être de séparer les accès aux bases de données en fonction des méthodes employées. En gros, les écritures avec un Backend SQL sur une DB d’écriture et les lectures avec un backend optimisé pour les lectures, sur une autre DB en slave. On enquête, mais le souci c’est que la relation master/slave de mysql ne permet que de faire de la lecture sur le slave.

En cas de cluster mysql, on va avoir plus de puissance pour l’ensemble mais tout le monde tapera toujours sur l’ensemble Mysql donc du coup le BO impacte de nouveau les perfs des serveurs frontaux. C’est une solution partielle, ca permet la scalabilité mais ce n’est pas encore le cas rêvé. Il serait possible d’atténuer cet effet en mettant une priorité plus faible aux requêtes provenant du BO qu’à celle provenant du FO mais je ne sais pas encore si c’est faisable. Avoir toute la DB en RAM aussi pourrait aider aevc un RAMFS mais cela ne changera pas tout non plus.

La dernière solution à laquelle je pense, c’est de créer un patch de Magento qui permettrait d’effectuer les opérations de backoffice et de frontoffice de façon différentes ou sur des bases différentes. Les écritures des serveurs de frontoffices (sessions utilisateurs) seraient faites dans la base de données Mysql Master en RW (Read Write) et les lectures sur la Slave RO (Read Only) pendant que le service de backoffice tape sur la master uniquement par exemple. Ca reviendrait à faire « à la main » la solution Zend évoquée ci-dessus.

On peut aussi tenter du master/master dans le cluster pour voir si les perfs sont meilleures…A suivre.

Pour commencer l’année du bon pied, voici ce que nous avons en cour de gestation dans le labo NBS pour faire de Magento une architecture à peu prêt efficace. Une fois vos sites optimisés, le code retravaillé, vos requêtes sql allégées, vos Magento mis à jour, bref, une fois les 32 règles d’or respectées, que faire pour gagner encore un peu ?

Si vous en êtes là, vous avez le même problème que les autres : la charge CPU des serveurs Web Frontaux quand ils rendent des pages et la charge imposée au serveur de base de données lors de l’utilisation du backoffice (B.O).

François soulignait que l’utilisation d’une instance séparée de Magento pour le B.O pourrait améliorer l’affaire et je suis bien de son avis. A tel point qu’on a cogité une optimisation sur notre plateforme C1 dédiée à l’hébergement de sites Magento.

Voici la recette :

1°) On crée un cluster de Mysql avec deux lames blindée de RAM, ce cluster on le paramètre en Mysql Master
2°) On crée un mysql non cluster sur une lame et on le paramètre en Mysql Slave (Entre le cluster et le serveur standalone, on a donc une réplication des informations écrite sur le master vers le slave)
3°) On met les serveurs de Frontoffice, les Web frontaux, sur une instance Magento qui s’adresse au cluster de base de donnée en Master
4°) On crée une instance Magento sur un autre serveur (voir techniquement sur un apache dédié sur un seul coeur d’un processeur), qui va pointer sur le serveur Mysql slave
5°) Sur la deuxième instance Magento (celle de B.O qui pointe sur le slave) on patch le framework Zend pour qu’il fasse ses opérations de Read (select notamment) sur le serveur Slave et ses opérations de Write sur le serveur Master (qui répercutera tout seul ses Insert, alter, Update, etc… sur le slave)
6°) On apprécie le fait que l’utilisation du B.O n’impacte plus les perfs client et le gain de performances associé my-connecteur-zend-DB

Work In Progress (W.I.P) :
- Le système de rendu des pages Web frontales pourrait être très optimisé en utilisant d’autres méthodes, on utilise Zend Optimiser et un (my)SQL analyzer pour jeter un oeil aux parties réellement trop consommatrices qui pourraient être patchées pour améliorer les performances et diminuer la pression de Magento sur les CPU.
- Une réflexion de fond est menée sur le fait que Zend permet l’interception de presque toutes les requêtes, méthodes, fonctions etc… à presque tous les niveaux. Vu que Magento repose dessus, il serait possible, sans toucher à Magento directement, d’optimiser ou repenser certaines fonctions. C’est principalement vrai pour les requêtes de bases de données puisque le reste de la page est conçu et « rendu » par Magento, mais il subsiste des pistes pour pouvoir remplacer certains appel à des fonctions lourdes par d’autres qui le sont moins, de manière transparente pour Magento, sans patcher son code source.

Bruno du labo vous présente ses voeux et offre le snippet de code (my-connecteur-zend-DB) qui permet l’arbitrage des DBs, pour l’utiliser, il suffit d’extraire le contenu du fichier « My.zip » en pièce jointe dans un dossier de l’include_path de PHP. La class My_Db_Statement_Clustered doit doc se trouver dans un dossier « My/Db/Statement/Clustered.php ». Si la fonction d’autoload de la class Zend_Loader n’a pas été activée, il faudra inclure ce fichier à la main (require_once()). Ceci fait, pour utiliser la classe, il suffit de placer le code suivant après l’instanciation des connections au base de données (Zend_Db_Adapter) comme ceci :

<?php
/**
* Redirige toutes les requêtes SQL de type INSERT, DELETE et UPDATE
* vers la connexion $myClusterDb
*
* @var Zend_Db_Adapter_Abstract $myClusterDb
*/

My_Db_Statement_Clustered::setWriteDatabase( $myClusterDb );
/**
* Redirige tous les autres types de requêtes SQL (SELECT, DESCRIBE, …)
* vers la connexion $mySlaveDb
*
* @var Zend_Db_Adapter_Abstract $mySlaveDb
*/

My_Db_Statement_Clustered::setReadDatabase( $mySlaveDb );
?>

Gilles nous explique aussi que des connecteurs natifs existent dans Magento, ca se règle dans app/etc/local.xml (voir le lien ici)