Caches et indexes : optimisez (vraiment) vos performances Magento

9 430 vues

Publié le

Cette présentation est tirée de la conférence technique que Matthieu BOUCHOT a donné début juin en tant que consultant de l’e-Commerce Academy, lors du Bargento 2013. Il y fait état des 2 faiblesses natives les plus graves selon lui, concernant la solution Magento, et propose des pistes d’optimisations dans chacun des cas.

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
9 430
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6 512
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Caches et indexes : optimisez (vraiment) vos performances Magento

  1. 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. 2. Scénario d’import de produits longs 1 import « Dataflow » 2 script automatique, ex. :
  3. 3. Scénario d’import de produits longs 3 utilisation de l’API SOAP/REST 4 MAGMI ou nouveau mécanisme import
  4. 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. 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. 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. 7. Mécanisme de cache Zend Framework • Save cache • Clean cache Paramètres   Clé  de  cache   Datas   Life0me   Tags   Paramètres   Tags  
  8. 8. Mécanisme de cache Zend Framework Clean cache : retrouver les clés associées à chaque tag (opération potentiellement coûteuse).
  9. 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. 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. 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. 12. Backend de caches : benchmark
  13. 13. Backend de caches : benchmark
  14. 14. Backend de caches : benchmark
  15. 15. Backend de caches : benchmark
  16. 16. Backend de caches : benchmark
  17. 17. Backend de caches : benchmark
  18. 18. Backend de caches : benchmark
  19. 19. A retenir sur le cache
  20. 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. 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. 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. 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. 24. Impact des indexes 1 locks de tables et d’enregistrements 2 ralentissements liés à des slow queries 3 deadlocks possibles
  25. 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. 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. 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. 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. 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. 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. 31. Benchmark : réindexation des urls avant 90saprès > 1h30 70k produits (55k simples, 15k configurables) répartis dans 200 catégories
  32. 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. 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. 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 !

×