fév 04

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 :)

écrit par Philippe Humeau \\ tags: , , , , ,

mar 31

La dernière version de Magento est sortie cette nuit et avec elle arrive l’option tant attendue : le Flat Catalog!

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!

écrit par Frédéric de Gombert \\ tags: , , ,

jan 08

Voici un rapide schéma qui montre comment se fait notre infrastructure actuelle :

archi-serveurs1


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 :


charge-cpu

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.

sessions

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

ram

Bref bref bref, que faire alors ? Lire la suite »

écrit par Philippe Humeau \\ tags: ,

jan 03

Tout d’abord, bonne année à toutes & à tous, que 2009 soit une année meilleure que prévue, voire même excellente, soyons fous :-)

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é :-) Lire la suite »

écrit par Philippe Humeau \\ tags: , , ,