Flat Catalog et performances : des résultats impressionnants

  • De le 20 février 2010
  • Difficulté : 2/4

Flat Catalog et performances : des résultats impressionnants Lors de son introduction dans la version 1.3 de Magento, le Flat Catalog fût une véritable révolution : conserver la souplesse du modèle EAV et accroître considérablement les performances par la simplification des requêtes. Un benchmark confirme amplement l'utilité du flat catalog...

L'activation de flat catalog a pour objectif de se soustraire du modèle EAV implémenté dans Magento. Modèle EAV largement critiqué pour les baisses de performance qu'il engendre, notamment pour les catalogues riches de plusieurs centaines de produits.

Le modèle EAV entraîne en effet une complexification importante des requêtes : de multiples jointures (parfois contraignantes pour le développeur) provoquant une multiplication des temps de traitement sur les données.

L'exemple suivant met en évidence une requête générée par Magento lors d'une interrogation sur une collection de produits :

Collection de produits

$collection = Mage::getModel('catalog/product')->getCollection()
                                ->addAttributeToFilter('weight',array('from'=>1))
                                ->addAttributeToFilter('price',array('from'=>5,'to'=>200))
                                ->addAttributeToSort('name')
                                ->getSelect();

echo $collection;

Lorsque que le catalogue à plat est désactivé, la requête SQL générée est la suivante :

Flat Catalog désactivé

SELECT `e`.*, `_table_weight`.`value` AS `weight`, `_table_price`.`value` AS `price`, IFNULL(_table_name.value, _table_name_default.value) AS `name`
FROM `catalog_product_entity` AS `e` INNER JOIN `catalog_product_entity_decimal` AS `_table_weight` ON (_table_weight.entity_id = e.entity_id)
AND (_table_weight.attribute_id='65') AND (_table_weight.store_id=0) INNER JOIN `catalog_product_entity_decimal` AS `_table_price`
ON (_table_price.entity_id = e.entity_id) AND (_table_price.attribute_id='60') AND (_table_price.store_id=0)
LEFT JOIN `catalog_product_entity_varchar` AS `_table_name_default` ON (_table_name_default.entity_id = e.entity_id) AND (_table_name_default.attribute_id='56') AND _table_name_default.store_id=0
LEFT JOIN `catalog_product_entity_varchar` AS `_table_name` ON (_table_name.entity_id = e.entity_id) AND (_table_name.attribute_id='56') AND (_table_name.store_id='1')
WHERE (_table_weight.value >= 1) AND (_table_price.value >= 5 and _table_price.value <= 200) ORDER BY `name` asc

Après génération et activation du catalogue à plat, la requête devient nettement plus abordable et compréhensible, dénuée de toute jointure :

Flat catalog activé

SELECT 1 AS `status`, `e`.`entity_id`, `e`.`type_id`, `e`.`attribute_set_id`, `e`.`weight`, `e`.`price`
FROM `catalog_product_flat_1` AS `e`
WHERE (e.weight >= 1) AND (e.price >= 5 and e.price <= 200)
ORDER BY `e`.`name` asc

Performances accrues (Versions 1.3.2.4 et 1.4.0.0)

Voici les résultats d'un benchmark réalisé sur les versions 1.3.2.4 et 1.4.0.0 de Magento, Flat Catalog activé puis désactivé (moyenne de 20 séquences). Les premiers tests ont été effectués sur un catalogue comportant quelques produits. La requête SQL utilisée est la même que précédemment.

Benchmark Flat Catalog

Ce qui saute immédiatement aux yeux c'est l'optimisation effectuée sur les scripts (construction de la requête) sur la dernière version de Magento (1.4.0.0). Sur une configuration équivalente, les temps d'exécution sont nettement inférieurs.

Petit paradoxe de la version 1.3.2.4, bien que le Flat Catalog diminue considérablement les temps de traitement des requêtes, il faut presque 2 fois plus de temps pour l'exécution des scripts (getCollection).

Le temps de traitement d'une requête sur un Flat Catalog désactivé dépendra du nombre de jointure, les données étant éparpillées dans les tables. Selon la complexité des attributs, les jeux d'attributs, et les différents types d'attributs (int, varchar, datetime, decimal...), l'interrogation sera évidemment plus ou moins longue. Le temps d'exécution de la requête en mode Flat sera sensiblement toujours équivalent, quelque soit la nature des données.

Avec quelques produits au sein du catalogue l'utilité d'utiliser le catalogue à plat apparaît déjà. Pour la suite des tests j'injecte dans le catalogue Magento 500 produits dont les données ont été générées de façon totalement aléatoire.

Produits CSV

J'exécute à nouveau la requête (les résultats présentent la moyenne élaguée de 20 requêtes) :

Benchmark Flat Catalog

Sur un catalogue conséquent les résultats sont sans équivoque. Sur notre requête nous obtenons des temps de traitement plus de 20 fois inférieure lorsque le Flat est activé. Ce résultat sera d'autant plus important que le nombre de produits du catalogue sera élevé. Le mode Flat permet également une homogénéité dans les temps de traitement des requêtes, une seule et unique table est interrogée, quelque soit les conditions appliquées et la nature des attributs.

Le graphique suivant présente l'évolution du temps de traitement de la requête (toujours la même) selon le nombre de produits, Flat Catalog activé et désactivé (Magento 1.4.0.0) :

Benchmark Flat Catalog

Le modèle EAV couplet au Flat Catalog fait de Magento une plateforme d'une souplesse encore jamais égalée, accompagnée de performances impressionnantes. L'ingéniosité des développeurs de Varien mérite d'être soulignée !

Pour la configuration des attributs avec le Flat Catalog, le site Magentips présente un très bon article : Flat catalog : attention à la configuration des attributs.

commentaires

Commentez cet article : Flat Catalog et performances : des résultats impressionnants