Caches et indexes : optimisez (vraiment) vos performances Magento

1. AFFINER LA GESTION DU CACHE OPTIMISER LES INDEXES ETUDES DE CAS ET OPTIMISATION DES PERFORMANCES Matthieu BOUCHOT Expert Magento @ The e-Commerce Academy

2. Scénario d’import de produits longs 1 import « Dataflow » 2 script automatique, ex. :

3. Scénario d’import de produits longs 3 utilisation de l’API SOAP/REST 4 MAGMI ou nouveau mécanisme import

4. Benchmark : sauvegarde produit save EAV 4% cleanCache BS 8% cleanCache AS 8% indexation 76% divers 4% $product-‐>save(); save EAV cleanCache BS cleanCache AS indexation divers

5. Pourquoi est-ce aussi long ? Mauvaise utilisation de dans une boucle. Conséquences : •  rafraîchissement du cache coûteux •  ré-indexation potentielle coûteux •  insert dans une structure EAV Ré-indexation totale dans le cas de Magmi ou import produit (excepté E.E 1.13)

6. Conséquences Mineures •  ralentissements pour les clients •  ralentissements pour les administrateurs Majeures •  durée de ré-indexation (donc des imports) •  locks DB •  indisponibilité serveur (web et/ou bdd)

7. Mécanisme de cache Zend Framework • Save cache • Clean cache Paramètres Clé de cache Datas Life0me Tags Paramètres Tags

8. Mécanisme de cache Zend Framework Clean cache : retrouver les clés associées à chaque tag (opération potentiellement coûteuse).

9. Mécanisme de cache Zend Framework Un cleanCache lent ralentit les performances du save et allonge la durée de transaction puisque le cleanCache model est exécuté dans le _afterSave.

10. Backend de caches Cache à 1 niveau •  File (par défaut) •  Database •  Cm_File •  Cm_Redis Cache à 2 niveaux •  Memcached + bdd •  Memcached + Redis •  Memcached + File •  Apc + (File/DB) •  Eaccalerator + (File/ DB)

11. Backend de caches Pourquoi deux niveaux? L’api memcached (ou apc) ne gère pas les tags donc la solution retenue est d’ajouter un autre backend de cache qui gère les tags. Inconvénients ? Le clean du cache devient lent puisqu’il faut retrouver dans le slow backend les associations puis boucler pour retirer les clés une à une.

12. Backend de caches : benchmark

19. A retenir sur le cache

20. Présentation des indexes Code Index/Table Quick Description catalog_product_attribute/ catalog_product_index_eav Contient les valeurs des attributs par produit de type listes déroulantes utilisés pour la navigation à facettes. catalog_product_price/ catalog_product_index_price Contient les valeurs de prix finaux/min/max de tous les produits à la date du jour. catalog_product_flat/ catalog_product_flat_[store_id] Contient les valeurs de (certains) attributs produits représentés sous forme de modèle plat : n’est utilisé en lecture que sur le scope frontend. catalog_category_flat/ catalog_category_flat_store_[store_id] Même remarque que pour l’entité produit.

21. Présentation des indexes Code Index/Table Quick Description catalog_category_product/ catalog_category_product_index Construit les associations catégories/produits en tenant compte des associations produits/ website + les propriétés ‘anchor’ + root category. catalog_url/ core_url_rewrite Construit les réecritures d’urls des produits/ catégories cataloginventory_stock/ cataloginventory_stock_status Combinaison des données (qty+status) des la table cataloginventory_stock_item + association produit/website catalogsearch_fulltext/ catalogsearch_fulltext Association produits ids/concaténation des attributs searchable.

22. Pourquoi est-ce si long/lent ? •  ajout de colonnes (tables flat) •  combinaisons pouvant être « explosives » •  locks au moment d’écrire dans les tables d’index (surtout pour les gros volumes) Indexe de prix Nombre de produits x nombre de groupes clients x nombre de websites Flat + Inventory + Category / Product + Product attribute Nombre de produits ou catégories x nombre de websites

23. Stratégie du « tout ou rien » Hors E.E. 1.13, Magento n’indexe que : •  produit par produit (en mode automatique) •  en ré-indexation totale Pas de réindexation partielle

24. Impact des indexes 1 locks de tables et d’enregistrements 2 ralentissements liés à des slow queries 3 deadlocks possibles

25. Solution de l’éditeur Sous Magento Enterprise 1.13… •  un système de trigger valorise des tables de changelog d’index (ne contient que les ids des entités à réindexer) •  un CRON parcourt les tables de changelog et réindexe les entités en fonction des ids qui s’y trouvent. Questions… •  cet automatisme permet t-il de désactiver les indexes que l’on ne veut pas indexer ? •  ordre de priorité d’exécution ? •  gestion du rafraîchissement du cache ?

26. Benchmark 0 1 2 3 4 5 6 7 EE 1.12 EE 1.13 Elapsed 8me in hours 1M Skus : Reindex All

27. Pistes de réflexion 1 réindexation partielle par sous-ensemble de produits 2 réindexation partielle de produits par propriété utile 3 réindexation partielle impactant seulement les propriétés modifiées

28. Réindex partiel, par sous-ensemble On ne réindexe ici que le sous-ensemble de produits désiré. Exemple avec le module ECA_Performance. On appelle :

29. Faible volumes : 400 produits/ 1 catégorie Volumes réels : 30k produits/10 catégories Benchmark Reindex All ~23s Reindex Par0el (10%) ~9s Reindex All ~30min Reindex Par0el (10%) <5min

30. Réindex partiel, par propriété utile On ne réindexe ici que les produits utiles : •  produits actifs et visibles dans le catalogue •  exclusion des produits simples déclinés des produits configurables •  les catégories sont exclues des urls produits Exemple avec un patch proposé par Dn’D.

31. Benchmark : réindexation des urls avant 90saprès > 1h30 70k produits (55k simples, 15k configurables) répartis dans 200 catégories

32. Réindexation partielle (3/3) On ne réindexe ici que les entités dont il est pertinent de mettre à jour l’index concerné en fonction des propriétés modifiées, quelques idées : •  on ne met à jour l’index des prix que si on modifie le prix du produits (à nuancer) •  on ne met à jour l’index des urls que si on modifie l’url du produit (à nuancer) •  on ne met à jour le flat catalog produit qu’en modifiant une valeur d’un attribut « utilisé dans le listing produit »

33. En conclusion Pour optimiser le cache •  penser aux backends Cm File ou Redis •  être pertinent sur ce qui est mis en cache Pour optimiser les ré-indexations •  développements spécifiques pour une gestion plus fine des indexes (modules e-Commerce Academy, patch Dn’d) •  suivre les bonnes pratiques (pas trop de stores, bon usage des groupes clients) •  Magento E.E 1.13

34. blog.academy-ecommerce.com www.academy-ecommerce.com contact@academy-ecommerce.com Twitter @ecommerce_acdmyFormation. Conseil. Audit. Le centre Magento de référence. Merci !