Parmi les petits trucs qu’il vaut mieux ne pas oublier sur un serveur à fort trafic, il y a la purge des sessions Magento. Si vous choisissez de stocker les sessions utilisateurs dans des fichiers (l’autre option étant de les stocker dans la base de données), ils viendront s’ajouter les uns après les autres dans le dossier var/session de Magento, sans jamais être supprimés.

Le problème, c’est qu’un serveur, même puissant et bien optimisé, accepte mal plusieurs millions de fichiers dans un seul dossier. Il devient même impossible de faire une simple commande ls pour lister son contenu : le serveur vous rendra la main plusieurs heures après… s’il y parvient !

Il faut donc purger les fichiers de sessions régulièrement. Les plus pressés feront un simple rm -rf du dossier session. C’est basique mais un peu brutal. Les utilisateurs et clients connectés ne vont pas forcément apprécier la perte de leur session et des commandes en cours…

J’ai eu le cas aujourd’hui sur un serveur dont la purge n’avait pas été mise en place. Avant de l’ajouter, j’ai vérifié que je pouvais gagner les longues minutes de purge de plus d’un millions de fichiers en supprimant directement le dossier session. Un rapide contrôle du trafic, des sessions et des commandes en cours : aïe, il y a trop de monde. Environ 200 sessions probables (selon temps de visite moyen) avec un taux de transformation de 6% et un panier moyen de 90€, ça me donne… 1080 € de pertes pour une simple commande rm -rf ! Un peu cher, je trouve. J’exécute donc une purge par date de fichiers et je laisse faire le serveur :

find . -atime +1 | xargs rm -f

90 minutes plus tard, tous les fichiers non utilisés depuis 48h sont supprimés (oui, +1 donne bien 2 jours, et non 1…). Je n’en ai plus « que » quelques milliers. Il reste à automatiser cette commande via crontab (en ajoutant les chemins absolus, bien entendu) et le tour est joué.

Sauf qu’il y a encore moyen d’améliorer tout ça, comme par exemple monter le dossier var de Magento en RAM. On gagne énormément en performances sur la gestions des sessions et du cache. Mais c’est une autre histoire…

Au passage , cette petite anecdote montre aussi qu’il ne faut jamais perdre de vue le métier de son client ou employeur. Certaines opérations menées sans réflexion et sans contrôle peuvent rapidement coûter très cher sur un site e-commerce. Il faut avoir en permanence le réflex d’évaluer la perte d’exploitation liée à une opération, même minime. En fin de mois, le cumul peut représenter bien plus que le salaire perçu…

Si l’activation du flat catalog est à peu près évidente (nous allons voir ça ci-après), il faut comprendre ce que fait Magento lorsqu’il crée les tables MySQL des produits à plat. Et on constate vite que, si on ne touche pas au paramétrage des attributs, on n’obtient pas du tout le résultat escompté !

Modèle EAV et flat catalog

Ce qui fait la souplesse de Magento, c’est la gestion de ses attributs par un modèle EAV. Chaque entité (produit, client, commande, etc.) est composée d’attributs (prix, couleur, pays, etc.) qui ont chacun une valeur (« 100 € », « vert », « France »). Comme un site évolue vite, on doit pouvoir ajouter ou retirer des attributs aux entités. Le modèle EAV est conçu pour cela, il permet de gérer facilement des attributs et leurs valeurs, sans modifier la structure de la base de données et sans écrire une seule ligne de code.

C’est un avantage énorme, mais il y a une contrainte de taille : quand Magento doit récupérer une entité (un produit par exemple), il doit parcourir un nombre important de tables dans la base de données pour assembler les valeurs des attributs et reconstituer l’information. Quand il faut afficher une page de catégorie avec 50 produits qui disposent chacun de 50 attributs, on arrive vite à la limite du tolérable. Comme le temps de réponse d’un site est le critère numéro 1 dans le succès d’un site e-commerce, il fallait trouver une réponse. Vous en réviez ? Magento le fait !

Pour accélérer les requêtes en lecture sur la base de données, Magento va construire de nouvelles tables dont chaque champ (ou colonne) représentera un attribut et chaque enregistrement (ou ligne) les valeurs des attributs d’une entité. C’est simple et rapide !

Bien entendu, si le catalogue est modifié, les tables doivent être reconstruites pour stocker les nouvelles informations. On ne met donc en œuvre des entités plates que si les valeurs ne changent pas tout le temps. Inutile d’y chercher les stocks ou les prix remisés par exemple.

Construire le flat catalog

Maintenant que les concepts de base sont posés, il faut savoir une chose : le flat catalog n’existe pas par défaut. Il faut donc le créer soit même depuis l’interface d’administration.

Pour créer un flat catalog :

• Menu Système > Gestion du cache
  
  Il faut d’abord construire les tables dans MySQL, grâce à ces boutons. On a le choix d’aplatir les catégories, les produits ou les deux.
• Menu Système > Configuration > Catalogue > Frontend
  
  Si nous ne construisons pas les tables via la gestion du cache, ces deux options sont indisponibles. Mais comme nous l’avons fait, nous avons maintenant le choix d’utiliser le flat catalog sur le frontend. Pourquoi faire compliqué alors qu’une seule étape pourrait suffire ? Simplement parce que Magento peut gérer plusieurs sites. On peut avoir un flat catalog sur un site et pas sur l’autre.
• Menu Système > Gestion du cache
  Oui, il faut y revenir pour ajouter nos entités (catégories et/ou produits) dans les tables à plat.

C’est tout. Mais est-ce suffisant ? Pas du tout ! Si on analyse les tables créées, on s’aperçoit vite que tous les attributs n’y sont pas, en particulier ceux spécifiques au site.

Si nous voulons afficher des valeurs d’attributs sans tuer les performances du serveur, il faut les ajouter à la structure des tables à plat. Pas de panique, inutile de faire ce sale boulot par des requêtes SQL hasardeuses. Magento a tout prévu… sauf de documenter ce détail essentiel !

Définir les attributs à aplatir

Quand nous demandons la construction du flat catalog, Magento utilise l’Indexer du module Catalog qui contient des contrôles sur la configuration des attributs (fichier Mage\Catalog\Model\Resource\Eav\Mysql4\Product\Flat\Indexer.php). Il contrôle notamment l’état du paramètre used_in_product_listing. S’il est égal à 1, l’attribut est intégré au flat catalog.

Reste à savoir d’où vient cet état. Une petite recherche (merci nWire !) et le voici, caché dans la configuration d’attribut (fichier Adminhtml\Block\Catalog\Product\Attribute\Edit\Tab\Main.php). On a la solution.

Pour ajouter un attribut dans le flat catalog :

• Menu Catalogue > Attributs > Gérer les attributs
  Sélectionner l’attribut à « aplatir ».
• Volet Propriétés du front-office
  
  C’est là que se cache l’option. Il faut choisir Oui et sauvegarder l’attribut.
• Menu Système > Gestion du cache
  On reconstruit le cache.

Le résultat est nettement meilleur. J’ai maintenant mon attribut dans mon flat catalog (ici manufacturer). Et un mystère de moins !