Améliorer les performances de VirtueMart : Proposition d’une nouvelle table

Antoine — Fri, 30 Jan 2009 17:48:41 +0000

Voici une proposition permettant d’améliorer le parcours de l’arborescence catégorie de VirtueMart, au détriment de la vitesse d’écriture. Ce billet fait directement suite à mon article « Améliorer les performances de VirtueMart« .

Cette méthode nécessite de créer une nouvelle table que nous appellerons #__{vm}_category_tree, dont voici le schéma :

category_id : identifiant de la catégorie
category_path : fil d’ariane de la catégorie sous forme d’un liste dénormalisée d’identifiant de catégorie séparée par « , »
level : niveau de profondeur de la catégorie étudiée

Par exemple, une catégorie ayant un « fil d’ariane » ayant pour valeur « ,1,6,184, » serait de niveau 4 (étant donné qu’il existe trois niveaux de catégories parentes). Sa catégorie parente serait la catégorie « 184″ qui aurait elle même comme parent « 6″ qui aurait elle même comme parent « 1″ qui n’aurait pas de catégorie parente.

Le choix du séparateur « , » permettra d’utiliser au besoin la colonne presque directement dans une requête SQL via le mot clé « in » si besoin.

Voici le SQL permettant de créer cette table :

CREATE TABLE IF NOT EXISTS `#__{vm}_category_tree` (
`category_id` int(11) NOT NULL,
`category_path` varchar(255) NOT NULL,
`level` int(11) NOT NULL,
KEY `category_id` (`category_id`),
KEY `category_path` (`category_path`),
KEY `level` (`level`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Pour alimenter cette table, il faut d’abord executer une fois la requete suivante :

INSERT INTO
`#__{vm}_category_tree`
(category_id,category_path,level)
SELECT
`#__{vm}_category.category_id`,
",",
1
FROM
`#__{vm}_category`
INNER JOIN
`#__{vm}_category_xref`
ON
`#__{vm}_category_xref`.category_child_id=`#__{vm}_category`.category_id
WHERE
`#__{vm}_category`.category_publish="Y"
AND
`#__{vm}_category_xref`.category_parent_id=0;

Il faut ensuite exécuter pour chaque niveau :

INSERT INTO
`#__{vm}_category_tree`
(category_id,category_path,level)
SELECT
`#__{vm}_category`.category_id,
concat(IFNULL(parent_leaf.category_path,""),`#__{vm}_category_xref`.category_parent_id,";"),
IFNULL(parent_leaf.level+1,0)
FROM
`#__{vm}_category`
INNER JOIN
`#__{vm}_category_xref`
ON
`#__{vm}_category_xref`.category_child_id=`#__{vm}_category`.category_id
LEFT OUTER JOIN
`#__{vm}_category_tree` parent_leaf
ON
parent_leaf.category_id=`#__{vm}_category_xref`.category_parent_id
WHERE
`#__{vm}_category`.category_publish="Y"
AND
`#__{vm}_category_xref`.category_parent_id IN (SELECT
category_id FROM `#__{vm}_category_tree` WHERE level=?)

Le remplissage « au fil de l’eau » de cette table, fera l’objet d’autres billets.

Maintenant pour connaître tous les enfants directs et indirects d’une catégorie (« 5″ par exemple), il suffit d’éxécuter la requête suivante:

SELECT category_id, level

FROM `#__{vm}_category_tree`

WHERE category_path LIKE ',5,%';

Une sacré économie de requetes SQL. Le résultat peut-être placée en cache si cela est possible. Il est également possible de complexifier cette requête en y rajoutant par exemple une jointure avec la table #__{vm}_category.

Si vous êtes intéressé par cette modification, merci d’appuyer ma demande sur le forum.

Améliorer les performance de Virtuemart : Constat

Antoine — Fri, 30 Jan 2009 12:55:19 +0000

Dans le cadre professionnel, il m’est arrivé à moi et à mes collèges de créer des boutiques en ligne, basées sur Joomla / VirtueMart, proposant plus de 15000 produits.

Après avoir réalisé des modifications nous permettant de tenir un tel catalogue, nous avons voulu les proposer à la communauté via le forum officiel de VirtueMart. Malheureusement, étonnement, notre demande a été ignorée pendant plusieurs mois.

L’un des problèmes majeurs, était le nombre de requêtes SQL nécessaires aux parcours de l’arborescence VirtueMart.

L’arborescence produit est stocké dans la table #__vm_category_xref dont voici le schéma simplifié :

category_parent_id : identifiant de la catégorie parent
category_child_id : identifiant de la catégorie enfant

Imaginons que votre site soit découpé en catégories de la manière suivante :

CMS
1. Joomla
  1. Joomla 1.0
  2. Joomla 1.5
  3. Joomla 1.6
2. Drupal
3. EZ Publish
4. Typo 3
E-Commerce
1. VirtueMart
2. Magento
3. OS Commerce

Ce découpage est bien en dessous de l’arborescence que nous avons à gérer pour nos sites e-commerce.

Pour récupérer, l’arborescence et l’afficher il nous faut d’abord récupérer les catégories sans enfants (« CMS » et « E-Commerce »). Pour chacune de ces catégories, il faut voir si ces dernières ont des enfants et les afficher. Cet algorithme continue de manière itérative…

On voit bien que le nombre de requêtes SQL nécessaire est exponentiel. Certes, il y a le cache, mais ce dernier n’est pas toujours utilisable (ie : en back office).

Pire, imaginons que la page affichant la catégorie « CMS » doivent afficher l’ensemble des produits contenus dans la catégorie « CMS » et dans ces enfants directs et indirects, le tout trié par prix.

Ce problème explique en partie la lourdeur de l’arborescence du back-office par défaut de VirtueMart , lorsque le catalogue produit est volumineux.

J’expliquerais en détail la méthode que nous souhaitons soumettre à la communauté dans un prochain billet.

Libre d'esprit » performances

Améliorer les performances de VirtueMart : Proposition d’une nouvelle table

Améliorer les performance de Virtuemart : Constat