Solution permanente au problème d'indexation courant

23

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é.

magento-1.7 ce-1.7.0.2 configuration performance ce-1.6.2.0 ravisoni
la source
J'ai perdu un an dans Magento et ses extensions et son architecture de données extrêmement inefficace et idiote qui fait un site de commerce électronique avec seulement 10K plus de produits en ruine. Tous ces avertissements auraient dû être donnés à quiconque commence à voir Magento CE. Onwers Magento devrait être poursuivi en justice pour avoir gaspillé des milliers d'heures de travail. Laissez simplement une base de données faire l'indexation, ne faites pas le travail d'une base de données. Je conseille qu'au lieu de gaspiller de l'argent sur un serveur dédié, puis des tonnes d'heures de travail pendant la nuit, il vaut mieux passer à une plate-forme de commerce électronique hébergée ou à une source ouverte qui utilise MS SQL Server.
semiprecious.com
Avez-vous déjà pensé que vous n'avez peut-être pas trouvé la bonne extension ou la bonne configuration de serveur? Si certains logiciels ne correspondent pas à vos besoins, cela ne signifie pas nécessairement qu'ils sont inutiles. Je gagne mon pain (et ma bière) depuis plus de 5 ans chez Magento et j'avais également beaucoup de clients satisfaits. Certains avec plus de 10k de catalogue.
Marius
Ils sont corrects, en raison de la façon dont CE fonctionne, la maintenance des données est un problème avec 10 à 100 milliers de skus. L'EE est meilleure en raison des mises à jour d'indexation qu'elles ont apportées, mais cela concerne les sociétés à revenus multiples de plusieurs millions de dollars. Vous pouvez y héberger, mais votre ROI sera négatif. La solution que nous utilisons est très spécialisée et les processus delta chargent des téléchargements similaires à des solutions telles que SAP et Walmart, combinés à une solution de tarification spéciale (ATG-esque) qui contourne le problème d'indexation (fx et recalques de marge / attribut en ligne), combinée avec le cluster l'hébergement. Réponse simple non, Magento n'a pas été conçu de manière optimale.

Réponses:

31

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.

Ben Lessani - Sonassi
la source
8

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:

entrez la description de l'image ici

philwinkle
la source
Nous apprécions les accessoires, mais la réindexation n'a rien à voir avec la mise en cache frontale; son entièrement une opération back-end. L'allégement de la charge frontale empêchera un ré-indexage de prendre plus de temps, mais ne le rendra certainement pas plus rapide.
Ben Lessani - Sonassi
Ce que je veux dire, c'est réduire le trafic entrant dans la boîte. La préoccupation ultime ici est que le site devient indisponible pendant l'indexation ou est verrouillé pendant une période de temps inconnue pendant l'exécution des travaux. En fin de compte, si l'indexation n'a pas eu d'effet négatif sur le frontend, la durée d'exécution du travail n'a pas d'importance. Il n'y a aucun correctif ou amélioration à l'indexation des temps de chargement. Personne ne veut une réponse "Mettre à niveau vers la version payante". Ma suggestion est donc d'améliorer la disponibilité de votre frontend et de planifier l'index pour qu'il fonctionne hors pointe.
philwinkle
Absolument, je l'ai compris - mais bien que la disponibilité soit importante pour un site Web; ce n'est pas suffisant pour un site de commerce électronique. Si vous ne pouvez pas réellement effectuer un achat en raison du verrouillage des index, le site peut également être hors ligne.
Ben Lessani - Sonassi
nous n'avons que quelques centaines de produits et il faut encore plusieurs minutes pour enregistrer un produit simple sur Magento 1.7, et je paie plus de 500 $ par mois pour un serveur Rackspace dédié. Je ne sais pas par où commencer, mais je soupçonne qu'un index est peut-être corrompu peut-être. Quelqu'un peut-il recommander un bon consultant magento?
Max Hodges
5

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.

rbncha
la source
@changeling, vous êtes les bienvenus. Je suis content que ça vaille la peine.
rbncha
J'ai intégré cela dans mon script, au cas où quelqu'un le trouverait utile: gist.github.com/steverobbins/…
Steve Robbins
4

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;)

simonthesorcerer
la source
Nous sommes généralement confrontés à un problème de produit plat, tous les autres indices sont corrects.
ravisoni
3

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/

maurisource web
la source
1

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

Paul Grigoruta
la source
2
Mais la plupart des clients préfèrent la version communautaire.
ravisoni
1
D'accord. La version 1.8 sera disponible dans quelques semaines, mais elle n'inclura probablement pas les optimisations de l'indexeur. Je n'aime pas ça non plus, mais c'est le moyen le plus simple, le plus sûr et peut-être le moins cher de faire fonctionner vos indexeurs.
Paul Grigoruta
est-ce impossible de trouver une solution permanente.
ravisoni
Dans la plupart des cas, lorsqu'une personne possède tellement de références SKU qu'elle se heurte vraiment à un mur de briques avec les indexeurs CE 1.7 existants, elle doit utiliser EE 1.13. Il existe de nombreux sites fonctionnant sans problème avec ces indexeurs CE 1.7 et EE 1.12 ayant 10-25k SKU. La clé est de les gérer directement au niveau du flux de travail et d'avoir la bonne infrastructure.
davidalger du
CE est un choix parfaitement adéquat. Les fonctionnalités d'EE 1.13 sont des corrections de bogues - que la communauté a de toute façon introduites dans CE. Indépendamment de cela et que vous utilisiez CE ou EE, le temps d'indexation dépendra entièrement de la complexité du catalogue, de la configuration du serveur, de la simultanéité des visiteurs et de la fréquence de réindexation. L'EE n'est pas une solution miracle et n'est certainement pas une solution appropriée pour tout problème lié à l'architecture.
Ben Lessani - Sonassi