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 »
Commentaires récents