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.