一般的なインデックス作成の問題に対する永続的なソリューション

私たちは、大きなインベントリレコードを持ついくつかのmagentoプロジェクトを開発し、フラットテーブルの切り捨てや、CLIを使用したcronの設定など、日々のインデックス作成の問題を解決するためにインターネット上で見つかったすべてのことを試してみました。インデックス作成ですが、これはインデックス作成の問題に直面している私たちの日々の頭痛です。

毎日製品を更新したり、他のフィードから製品を毎日インポートしたりするなど、さまざまなシナリオがあるプロジェクトに取り組んでいる間、この問題に対する永続的なソリューションを探しています。

これまたはいくつかの回避策でいくつかのベストプラクティスをお持ちの方は、非常に高く評価されるそれらを共有してください。

どのインデックスが遅いのか、そしてその理由を理解することが重要です

カタログの複雑さと最終的なストアアーキテクチャにより、インデックスの再構築にかかる時間と、基盤となるインフラストラクチャの組み合わせが決まります。

• 50,000個の製品と10個のストアビューがある場合、数百万行のcatalog_url_rewrite処理に時間がかかることを保証できます。

• あなたは100個の製品が、5000の属性を持っている場合は、保証することができcatalog_attributesたりcatalog_product_flat、テーブルを再構築するために年齢を取るか、だろう秋のフラットをその顔に

• 1,000個の製品があり、500個の検索可能な属性がある場合、catalog_fulltext_search完了するには再び年齢がかかります

あなたが直面するそれぞれの問題に対する解決策はすべてに適合するサイズではありません。それはあなたの店を適切に設計することです。それをサポートする適切なインフラストラクチャを用意し、コンテンツの最新性とパフォーマンスをサポートする再インデックスの頻度/戦略を使用します。

• フロントエンドキャッシュを追加してもまったく役に立ちません
• その状況でより多くのハードウェアを投げると
• カタログのサイズ/複雑さに対処すると役立ちます
• サードパーティのインデックス作成ツールを使用すると役立ちます
• 特定のインデックスの外部化（例：検索> SOLR）が役立ちます

特定のインデックスが必要かどうかを評価する場合もあります。フラットな製品/カテゴリを使用しても、すべての店舗が常に高速になるとは限りません。店舗がかなり遅くなるのを見てきました。そのため、前後にパフォーマンスをテストした後、それらは考慮事項ではないことに気付くかもしれません。

tl; dr

特効薬のソリューションはありません。いくつかの回避策がありますが、それはSonassi_Fastsearchindexカタログ検索専用です。

おそらく、保存時にインデックスの更新を無効にする（夜間に実行するようにスケジュールする）ことで、多少の軽減が得られるでしょうか？さらに多くのキャッシング（memcached、Redis、APC）およびVarnish（CEを実行している場合）のようなフルページキャッシュを追加することと組み合わせることで、始めることができます。Varnishを使用する予定がある場合はNexcess_Turpentine、githubでクイックスタートを確認してください。

詳しくは

インデックス作成の問題-特にcatalog_url_rewrites-はよく知られ、コミュニティで文書化されています。Magentoは、これらが最も悪影響を受ける顧客であるため、Enterpriseバージョンでこれらを処理しました。多くのEE顧客は、1万以上の製品と複数のストアビュー、Webサイトなどを持っています。

ただし、大規模なカタログと多数の属性がある場合、インデックス作成に長時間かかるという状況に陥ることがあります。具体的には、catalog_url_rewrite、product_flatです。この場合、インデックスの実行時間を修正しないことをお勧めします。長さではなく、処理をオフロードして、コンテンツを提供するのではなく、CPUサイクルのインデックス作成にボックスを使用できるようにします。

自問する質問：

• インデックス作成の問題でビジネスを失いますか？
• 負けアムI 生産性を伴うインデックスの問題のために？
• コンバージョンを失うリスクがありますか、またはコンバージョン率が低下していますか？
• インデックスが同期していない直接の結果である在庫（在庫など）を顧客が購入するリスクがあるか
• カタログ価格設定ルールはコアビジネスの一部であり、
• オンサイト検索のコンバージョン率は標準（8〜10％）よりも高いので、インデックス作成のメリットがありますか？

この特定の問題に対する特効薬の解決策はありません。ソリューションプロバイダーとして、オーバーヘッドコストを低く抑えながら、売上とビジネスを改善する最適な意思決定を顧客が行えるようにする必要があります。

代替案

カタログ検索と階層化ナビゲーションをSolrにオフロードします。

水平方向に拡大縮小します。さらにApache / nginxサーバーを追加します。より多くのサーバー=より多くの同時スループット。これは1：1ではありません。Nexcessには、パフォーマンスとApacheの構成に関する素晴らしいホワイトペーパーがあります：http : //www.nexcess.net/magento-best-practices-whitepaper

そして、あなたがワニスと一緒に行くことを選択した場合-覚えている

大規模なMagento Webショップのほとんどでは、Magentoバックエンドインデックス管理を機能させるのは非常に困難です。私はこの問題を頻繁に経験しました。開発者がシェルスクリプトを常に実行するのは多忙です。通常、私はこの問題を永久に修正します。

shell / indexer.phpの新しいコピーを作成します> shell / myindexer.php

shell / myindexer.phpを154行目付近にカスタマイズします

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

に

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

そして、このチェックを166行目に追加します

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

前

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

そして、新しいシェルスクリプトをcpanel cronに追加して、5分ごとに実行します

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

上記のシェルスクリプトは5分ごとに実行され、再インデックス付けが必要なプロセスのみを再インデックス付けするため、サーバーCPUに大きな負荷がかかるリスクが軽減され、再インデックス付けのプロセス全体が非常に高速になります。再インデックス付けが必要なプロセスがない場合、単に再インデックス付けプロセスは実行されません。また、インデックス管理ページで再保存モードを「保存時に更新」に設定することを忘れないでください。わからない場合は、[送信]ボタンの横にある[アクション]> [インデックスモードの変更]でこのオプションを取得できます。

より多くのデータ（在庫サイズ、訪問者、マシン）を提供できると言う方が簡単ですが、可能性は次のとおりです。

• Sonassi_Fastsearchindexカタログ検索インデックスに拡張機能を使用します。タイトル、説明、およびsku（私は気づいたと思います）のインデックスを作成するだけですが、うまく機能し、カタログ検索インデクサーの時間を短縮します。
• ほとんどの場合、実行する必要のないインデクサー（タグや製品属性など）があります。定期的に価格、製品フラット、カテゴリー製品、カタログ検索のみを行えば十分な場合があり、その他は毎日行う場合があります。
• 2時間ごとに製品を外部システムと同期し、その間、phpスクリプトでインデックスを作成します。そのため、特定の時間に実行する各インデクサーのcronjobを用意し、このcronにスクリプトを実行させます。これは、サーバーが実行できることと最新の製品データの間の最適な中間手段のようです。

これは、Magento CE 1.7.0.2で実行されています。それでも痛みはあります;）

Dnd_Patchindexurlを使用して、catalog_url_rewriteの再インデックス時間を約70％に短縮できました。

無効な製品や表示されない製品を除外して、URLを無料で作成することは良い解決策だと思います！

$ 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

後：

$ 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

1.9.1.1にインストールし、非常にうまく動作しました！

Connect経由でもインストールできますhttp://www.magentocommerce.com/magento-connect/catalog/product/view/id/15074/s/dn-d-patch-index-url-1364/category/12863/

EE 1.13にアップグレードします。このバージョンでは、インデクサーが大幅に改善されました。