Magento Flat catalog : attention à la configuration des attributs !

Depuis Magento Community Edition 1.3.0, nous obtenons de bien meilleures performances sur le frontend, grâce au catalogue à plat ou flat catalog. Varien a introduit ce concept pour optimiser les temps de réponse des sites qui offrent un catalogue riche (aux alentours de 1000 produits, mais le seuil est très variable selon complexité des attributs, des jeux d’attributs et des types de produits).

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 !

Avertissement !
Cet article est très ancien et son contenu peut s'avérer obsolète.

Commentaires

volt

Merci beaucoup , tu est mon héro T_T

3 mars 2010, 11h21 · Répondre

jaouad hammoumi

très intéressant, tu es un pro, merci bcp!

12 mars 2010, 11h23 · Répondre

plancton

Notons que l’attribut status ne figure pas dans le catalogue à plat alors qu’il est bien par défaut « used_in_product_listing ». (En tous cas chez moi)
D’ailleurs, je ne sais pas si c’est pour cette raison que le produit reste dispo même si je le désactive (product->getSatus renvoie toujours 1 ???!!)

25 mars 2010, 11h59 · Répondre

Damien

Si j’ai bien compris on définit une première fois la structure de la base de données via la back end et ensuite avec l’option flat catalog activée magento génère la base de données correspondante. Ma question est la suivante, est ce que l’on peut faire évoluer la structure de nos tables au fur et à mesure de l’avancement dans le temps malgré le fait qu’il y est déja des données

9 décembre 2010, 16h30 · Répondre

Christophe

@ Damien
Oui, bien sûr. On peut faire n’importe quelle modification sur les attributs. Il faut simplement penser à reconstruire les tables à plat juste après. Si on l’oublie, Magento nous le rappelle dans toutes les pages du backend.

Important : la reconstruction des tables à plat prend pas mal de ressources machine, il vaut mieux la faire quand le trafic est faible.

11 décembre 2010, 11h44 · Répondre

Ajouter un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *