Solution permanente au problème d'indexation courant

Nous avons développé un projet magento avec un grand inventaire et nous sommes toujours confrontés au problème d'indexation que nous avons essayé tout ce qui se trouve sur Internet pour résoudre le problème d'indexation au quotidien, comme tronquer les tables plates et réindexer à l'aide de CLI, en définissant le cron pour l'indexation, mais c'est notre mal de tête au quotidien face à un problème d'indexation.

Nous recherchons une solution permanente à ce problème pendant que nous travaillons sur des projets, il existe différents scénarios comme la mise à jour quotidienne des produits ou l'importation quotidienne des produits à partir d'un autre flux.

Quiconque ayant quelques bonnes pratiques avec ceci ou une solution de contournement, veuillez les partager, ce qui sera très apprécié.

Il est important de comprendre quels index sont lents et pourquoi

La complexité du catalogue et, finalement, l'architecture du magasin dicteront la durée d'un réindexage, combinée à l'infrastructure sous-jacente.

• Si vous avez 50 000 produits et 10 vues de magasin, vous pouvez garantir les quelques millions de lignes catalog_url_rewrite traitement de prendra du temps.

• Si vous avez 100 produits, mais 5 000 attributs, vous pouvez garantir que la table catalog_attributesou catalog_product_flatprendra un certain temps pour se reconstruire ou tomber à plat sur son visage

• Si vous avez 1 000 produits, mais 500 attributs consultables, alors catalog_fulltext_search faudra encore un certain temps pour terminer

La solution à chaque problème que vous rencontrez n'est pas une taille unique, il s'agit d'architecturer correctement votre magasin; avoir la bonne infrastructure en place pour la prendre en charge et utiliser une fréquence / stratégie de réindexation qui prend en charge la récence et les performances du contenu.

• L'ajout de la mise en cache frontale n'aidera pas du tout
• Lancer plus de matériel sur la situation pourrait
• Le traitement de la taille / complexité du catalogue aidera
• L'utilisation d'outils d'indexation tiers vous aidera
• L'externalisation de certains index (par exemple, recherche> SOLR) aidera

Il y a aussi le cas d'évaluer si certains index sont même nécessaires. L'utilisation de produits / catégories plats ne rend pas toujours tous les magasins plus rapides; nous l'avons vu ralentir les magasins. Donc, vous pourriez constater qu'après avoir testé les performances avant / après - ce n'est même pas une considération.

tl; dr

Il n'y a pas de solution miracle. Il existe certaines solutions de contournement, je suggère Sonassi_Fastsearchindex- mais c'est spécifiquement pour la recherche dans le catalogue.

Peut-être que la désactivation des mises à jour d'index lors de la sauvegarde - la planification pour s'exécuter pendant la nuit - apportera un soulagement? Combiné avec l'ajout de plus de cache - memcached, Redis, APC - et un cache pleine page comme Varnish (si vous utilisez CE) peut vous aider à démarrer. Si vous prévoyez d'utiliser Varnish, regardez Nexcess_Turpentinesur github pour un démarrage rapide.

Plus d'information

Les problèmes d'indexation - en particulier catalog_url_rewrites - sont bien connus et documentés dans la communauté. Magento a géré ces problèmes dans la version Enterprise car ce sont les clients qui sont les plus touchés. De nombreux clients EE ont plus de 10 000 produits et plusieurs vues de magasins, sites Web, etc.

Cependant, si vous avez un grand catalogue et un grand nombre d'attributs, vous pouvez vous retrouver dans la position que l'indexation prendra une longue période - spécifiquement catalog_url_rewrite, product_flat - dans ce cas, ma suggestion n'est pas de fixer le temps d'exécution de l'index longueur mais plutôt pour décharger un certain traitement afin de permettre à la boîte de passer des cycles CPU à indexer plutôt qu'à servir du contenu .

Les questions à se poser:

• Suis-je en train de perdre des affaires en raison de problèmes d'indexation?
• Suis-je en train de perdre de la productivité en raison de problèmes d'indexation?
• Suis-je à risque de perdre des conversions ou mon taux de conversion souffre-t-il?
• Mes clients risquent-ils d'acheter des articles en rupture de stock qui résultent directement de la désynchronisation des index (inventaire, etc.)
• Mes règles de tarification de catalogue font-elles partie de mon activité principale et
• Mon taux de conversion de recherche sur site est-il supérieur à la norme (8-10%), bénéficiant ainsi d'une meilleure indexation?

Il n'y a pas de solution miracle à ce problème particulier - en tant que fournisseur de solutions, vous devez aider votre client à prendre la décision qui améliorera le mieux les ventes et l'entreprise tout en réduisant les frais généraux.

Alternatives

Décharger la recherche de catalogue et la navigation en couches vers Solr.

Échelle horizontalement. Ajoutez d'autres serveurs Apache / nginx. Plus de serveurs = plus de débit simultané. Ce n'est pas 1: 1. Nexcess a un excellent livre blanc sur les performances et la configuration d'Apache ici: http://www.nexcess.net/magento-best-practices-whitepaper

Et, si vous optez pour le vernis, n'oubliez pas:

Dans la plupart des boutiques en ligne de Magento, il a été très difficile de faire fonctionner la gestion d'index du backend de Magento. J'ai souvent eu ce problème. L'exécution du script shell tout le temps par le développeur est souvent mouvementée. Habituellement, je résous ce problème de manière permanente comme ceci.

Je crée une nouvelle copie de shell / indexer.php> shell / myindexer.php

Personnalisez shell / myindexer.php autour de la ligne 154

} else if ($this->getArg('reindex') || $this->getArg('reindexall')) {

À

} else if ($this->getArg('reindex') || $this->getArg('reindexall')  || $this->getArg('reindexallrequired') ) {

et, ajoutez cette vérification autour de la ligne 166

//reindex only if required
if( $this->getArg('reindexallrequired') && $process->getStatus() == Mage_Index_Model_Process::STATUS_PENDING )
    continue;

avant

$startTime = microtime(true);
$process->reindexEverything();
$resultTime = microtime(true) - $startTime;
Mage::dispatchEvent($process->getIndexerCode() . '_shell_reindex_after');

Et puis j'ajoute le nouveau script shell à cpanel cron pour qu'il s'exécute toutes les 5 minutes

/home/public_html/shell/indexer.php --reindexallrequired >/dev/null

Comme le script shell ci-dessus s'exécute toutes les 5 minutes et qu'il ne réindexe que les processus qui nécessitent une réindexation, il réduit le risque de forte charge sur le processeur du serveur ainsi que l'ensemble du processus de réindexation est très rapide. Si aucun processus ne nécessite une réindexation, il n'exécutera tout simplement pas le processus de réindexation. N'oubliez pas non plus de mettre le mode de réindexation sur "Mettre à jour lors de l'enregistrement" dans la page Gestion de l'index. Si vous ne le savez pas, vous pouvez obtenir cette option dans Actions> Changer le mode d'index à côté du bouton Soumettre.

Il serait plus facile de dire si vous pourriez donner plus de données (taille de l'inventaire, visiteurs, machine), mais voici une possibilité:

• nous utilisons l' Sonassi_Fastsearchindexextension pour l'index de recherche de catalogue. Bien qu'il indexe simplement le titre, la description et le sku (je pense l'avoir remarqué), il fonctionne très bien et réduit le temps d'indexation de la recherche de catalogue.
• il y aura très probablement des indexeurs que vous n'aurez pas à exécuter, par exemple pour les balises ou les attributs de produit. C'est parfois suffisant si vous ne faites que des prix, des produits plats, des catégories de produits et des recherches de catalogue régulièrement, et les autres peut-être quotidiennement.
• nous synchronisons les produits avec un système externe toutes les deux heures, et en attendant, nous indexons avec des scripts php. Donc, nous avons un cronjob pour chaque indexeur que nous voulons exécuter jusqu'à un certain moment, et laissez ce cron exécuter le script. Cela semble être le meilleur moyen entre ce que le serveur peut faire et des données produit à jour.

Cela fonctionne sur Magento CE 1.7.0.2; encore une douleur, cependant;)

en utilisant Dnd_Patchindexurl, j'ai pu réduire le temps de réindexation catalog_url_rewrite à près de 70%

Je pense que c'est une bonne solution pour exclure les produits désactivés ou les produits non visibles d'avoir leur URL créée pour rien!

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:11
Product Prices index was rebuilt successfully in 00:00:22
Catalog URL Rewrites index was rebuilt successfully in 00:08:49
Product Flat Data index was rebuilt successfully in 00:00:51
Category Products index was rebuilt successfully in 00:00:19
Catalog Search Index index was rebuilt successfully in 00:00:12
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

Après:

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:12
Product Prices index was rebuilt successfully in 00:00:24
Catalog URL Rewrites index was rebuilt successfully in 00:02:52
Product Flat Data index was rebuilt successfully in 00:00:57
Category Products index was rebuilt successfully in 00:00:25
Catalog Search Index index was rebuilt successfully in 00:00:13
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

Je l'ai installé sur 1.9.1.1 et fonctionne très bien!

Peut également être installé via Connect http://www.magentocommerce.com/magento-connect/catalog/product/view/id/15074/s/dn-d-patch-index-url-1364/category/12863/

Mise à niveau vers EE 1.13. Les indexeurs ont été considérablement améliorés dans cette version.