Pourquoi le checkout PrestaShop ralentit quand vous ajoutez un moteur de recherche externe

Un effet de bord auquel on ne s'attend pas

On installe Elasticsearch, OpenSearch ou Meilisearch sur PrestaShop presque toujours pour une seule raison : la recherche native ne suit plus sur un gros catalogue. Et la recherche s'améliore effectivement. Ce que l'on vérifie moins souvent, c'est ce qui arrive au reste de la boutique, en particulier au panier et au checkout, quand cet index externe doit rester synchronisé avec le stock et la disponibilité, qui changent à chaque vente.

Si cette partie passe souvent inaperçue, c'est pour une raison simple : en démonstration, avec une poignée de commandes, rien ne se voit. Le problème apparaît sous une charge réelle, quand plusieurs commandes arrivent en même temps, et à ce moment-là le client est déjà en train de payer. Ce n'est pas l'endroit où l'on souhaite découvrir un goulot d'étranglement.

Ce qui doit se passer quand un client modifie une quantité dans son panier

Avec un moteur de recherche externe, chaque produit existe deux fois : une ligne dans la base de données de PrestaShop, et un « document » dans l'index du moteur de recherche, qui contient les champs nécessaires pour le trouver et le filtrer (nom, prix, catégories, disponibilité, etc.). Quand un client ajoute un produit au panier, modifie une quantité ou qu'une commande est validée, la disponibilité de ce produit change, et le document de l'index doit en tenir compte, sinon un autre client pourrait voir disponible un produit qui vient d'être épuisé.

La façon la plus simple de le faire, et aussi la plus coûteuse, consiste à reconstruire tout le document à chaque fois : relire depuis la base le nom, la description, le prix, les catégories, les images et tout le reste, pour mettre à jour trois chiffres (quantité, disponibilité, ordre de tri selon la disponibilité). Si cette reconstruction se déclenche une fois par ligne de commande, une commande de cinq produits différents la déclenche cinq fois, précisément au moment où le client attend la confirmation de son paiement.

Les chiffres réels

Mesurée sur PrestaShop 9.0.0, avec deux boutiques connectées à Elasticsearch, une commande de cinq lignes qui reconstruisait le document complet pour chaque ligne coûtait 243 requêtes SQL et 229 millisecondes, uniquement pour déplacer trois chiffres dans l'index de recherche. Ce n'est pas le temps du checkout complet, c'est le temps d'une seule étape à l'intérieur, celle qui maintient l'index synchronisé.

Avec un chemin dédié qui ne met à jour que les champs réellement modifiés (quantité, disponibilité, ordre selon la disponibilité) au lieu de reconstruire tout le document, la même commande sur les mêmes boutiques est descendue à 9 requêtes et 16 à 47 millisecondes. Même opération, même résultat final dans l'index : seule change la quantité de travail nécessaire pour y arriver.

La différence technique s'explique facilement, même à quelqu'un qui n'écrit pas de code : un moteur de recherche externe propose normalement deux façons de mettre à jour un document. La première, « le remplacer entièrement », sert quand quelque chose de structurel change vraiment, comme le nom ou le prix. La seconde, « ne mettre à jour que ces champs », est prévue pour le cas bien plus fréquent où seule la disponibilité change. Utiliser toujours la première, même quand la seconde suffit, est la cause la plus courante d'un checkout qui ralentit justement quand la boutique vend davantage.

Pourquoi cela arrive presque toujours au même endroit

Dans PrestaShop, l'événement qui signale un changement de quantité pendant une commande peut se déclencher une fois par ligne de commande, et non une fois pour toute la commande. Il est facile d'écrire le code qui écoute cet événement en se disant « ce n'est qu'une mise à jour », sans remarquer que sur une commande de nombreuses lignes, ou lors d'un pic de ventes avec beaucoup de commandes simultanées, ce simple choix se multiplie par le nombre de lignes et par le nombre de commandes en cours au même moment. Un module de recherche qui semble rapide en test avec une commande à la fois peut se comporter très différemment pendant un Black Friday avec des centaines de checkouts simultanés.

Ce qu'il faut demander si vous avez déjà un moteur externe

• Demandez à votre module de recherche ou à votre intégrateur si une modification de quantité dans le panier met à jour uniquement les champs de stock, ou reconstruit tout le document produit.
• Faites un test avec une commande de plusieurs lignes à un moment calme et surveillez le journal des requêtes lentes de la base pendant le checkout : si vous voyez des dizaines de requêtes répétées pour le même produit, c'est exactement ce symptôme.
• Si vous gérez une boutique B2B ou de vente en gros avec des paniers de nombreuses lignes, ce problème évolue mal : un panier de trente lignes avec une reconstruction complète par ligne est six fois plus lent qu'un panier de cinq lignes, alors qu'avec une mise à jour ciblée la différence est bien plus faible.
• Ce n'est pas une raison pour renoncer à un moteur de recherche externe : un gros catalogue en a toujours besoin pour la recherche. C'est une raison de vérifier comment l'intégration entre le panier et l'index a réellement été écrite.

En résumé

Un moteur de recherche externe ne ralentit pas le checkout à lui seul. Ce qui ralentit le checkout, c'est une intégration qui reconstruit tout le document de recherche pour un changement qui ne concerne que trois chiffres. La différence mesurée, de 243 requêtes et 229 millisecondes à 9 requêtes et 16 à 47 millisecondes sur la même commande, correspond au travail que nous avons fait dans cll_essearch en séparant les mises à jour de stock des mises à jour structurelles sur Elasticsearch, OpenSearch et Meilisearch. Si votre boutique utilise un moteur externe et que le checkout ralentit justement quand les ventes décollent, c'est la première chose à vérifier.

Recherche Elasticsearch et Navigation à FacettesRecherche ultra-rapide, tolérante aux fautes de frappe, avec navigation à facettes moderne en panneau modal, a…99,99 €Voir le produit