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.

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

13. Backend de caches : benchmark

14. Backend de caches : benchmark

15. Backend de caches : benchmark

16. Backend de caches : benchmark

17. Backend de caches : benchmark

18. 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 !