Magento Automatic Caching Insight

memcacheを使用してMagento EE 1.11を実行しています。memcahceサーバーあたり2GB、合計4GB。約240kの製品があります。

• 使用可能なRAM：6GB
• コア：16
• スレッド：32

これが取引です。新しい製品が追加され、製品の変更が毎日行われます。もちろん、新しい製品がバックエンドで追加/変更されるたびに、キャッシュ、特に「フルページキャッシュ」が無効になります。

Magentos Auto Cache Generationを有効にすると、クローラーに8つのスレッドが割り当てられ、キャッシュの構築に約2日かかります。2日後、memcacheは2つのRAMディスク間で約2GB浮きます。

問題は、製品が毎日変更されると、キャッシュが無効になり、「フルページキャッシュ」が更新されるとすぐに、それらの2GBのキャッシュが1に戻り、Magentos Autoキャッシュの粘性サイクルが再び開始されることです。キャッシュが0に戻るだけでなく、CPU使用率が90％に急上昇し、ウェブサイトが5〜10秒以上待機するゲームに変わります。100種類以上のバリエーションがある製品をリクエストしようとするのを忘れることができます。キャッシュされていないので、初めてロードするのに数分かかります、それはばかげています。

だから、コミュニティへの私の質問。

• Magentoが無効になった場合、キャッシュ全体を再構築せずに0から開始せずにキャッシュを自動的に「更新」する方法はありますか？キャッシュが無効になると、Magentoは何かが変更されたことを認識しますが、キャッシュ内の正確な場所はわかりません（間違っている場合は修正してください）。キャッシュ全体の再構築をバイパスするモジュール/構成はありますか？

補足として、Tiny Bricks LightSpeedモジュールを使用しています。

• Magentos自動キャッシュ生成は、cronジョブで時間制御できますか？午後10時から午前6時にクロールを開始するとします。

• この状況に対処する最善の方法は何でしょうか？、あなたが理解しているように、毎日ギガバイト単位のキャッシュを再構築することは受け入れられません。

十分なRAMがありません

約240kの製品が
あります。使用可能なRAM：6GB
スレッド：32

所有する製品の量に対して十分なRAMがありません。経験則として、論理コアあたり少なくとも2〜4 GBのRAMをお勧めします。

可能なメモリ使用量をマップする場合：

• max_memory〜768MB = 24GBの 64個のPHPスレッド
• 240,000の製品は、おそらく15GBのInnoDB表スペースを意味します
• 64個のPHPスレッドは約128個のMySQL接続を保証します。通常、これには接続ごとに約200MBのコストがかかります
• Redisおよびlzf圧縮された240,000製品のバックエンドストレージ-約6GBのRAMを引き続き消費します

したがって、これまでの合計は70GBのコミット済みRAMです。OSなどについても言及していません。

ハードウェアの仕様がひどく不十分です。このMagentoサーバーのセットアップに関する記事を読んで、進行方法を少し理解してください。

Memcachedはキャッシュタグをサポートしていません

Memcachedを使用している場合（問題ではなく、非常に高いパフォーマンス）、キャッシュタグを保存しているかどうかのどちらかです。slow_backend定義されていない場合-タグを保存していないため、基本的にキャッシュは異なるキャッシュタイプを区別できないため、それらを個別にフラッシュすることはできません。

これについては、http：//www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/をお読みください。

Redisに切り替えることを強くお勧めします。癖があり、大規模な店舗では大幅な微調整が必​​要です。しかし、全体としては、Memcachedよりもわずかに優れたパフォーマンスを発揮しますが、キャッシュタグサポートの真の利点があります。

404とFPC

FPCには実際の問題があり、事実上、すべてのキャッシングエンジンには404の問題があります。その理由は、まだクロールまたはリンクされている古いURLは、core_url_rewriteテーブル全体を反復処理するページに到達し、最終的に404を放棄してロードする前に、定義されたすべてのルーターと名前空間との一致を見つけようとするからです。

次に、値を持たず、キャッシュストレージのスペースを消費するリソースをキャッシュします。おそらく、Memcachedストレージの大部分が実際に404コンテンツに食われていることがわかるでしょう。

大きなカタログ（240kの製品）を使用すると、製品の売上高のかなりの部分が確実に得られるため、URLの変更とそれに続く多くの404が発生します。

FPC無効化とクリーン化

現時点では-およびデフォルトで-FPCの動作は、単にキャッシュエントリを無効にするのではなく、変更時にキャッシュを消去することです。EEストアがこの動作を変更して、必要なことを正確に行うための拡張機能を作成しました。

ここに、問題を解決する方法のアイデアを提供する簡単なパッチがあります。

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

クローラーを実行しないでください

十分な足取りがある場合-クロールツールを実行することはお勧めしません。不必要な負荷が発生します。サイトを閲覧している人/ボット/クローラーは、キャッシュを準備しておく必要があります。

しかし、質問に答えるために、上記の構成ファイルを見ると、クロールブラウジングウィンドウ用に定義されたcronスケジュールが表示されます。

古いコンテンツに余裕がある場合

そして最終的に、十分な RAM があれば。FPCに保存されているコンテンツのTTLを増やすと、キャッシュされたデータをより長く存続させることができます。

では<full_page_cache>では、タグ、あなた./app/etc/local.xmlだけの定義

<lifetimelimit>86400</lifetimelimit>

ライフタイムは秒単位で定義されます。コンテンツの鮮度、パフォーマンス、および実際に利用可能なストレージ容量のバランスをとる必要があります。

EEでサードパーティのキャッシュ拡張機能を使用する理由

あなたはFPCにプレミアムを支払っています-それは非常に良いことです。それでは、なぜサードパーティの代替を上から実行しているのでしょうか。それを除く。

このように置きます。あなたの車がひどく走っていた場合-補償するためにブートに別のエンジンを追加しますか？または単にそこに既にエンジンを修正しますか？

私たちはあなたをとてもよく理解しています！毎日新しい製品を追加したり、製品を変更したり、静的ブロックも変更します。そのため、無効化されたMagentoキャッシュと、システム->キャッシュ管理に進むこの定数でいっぱいになりました。無効化されたキャッシュタイプを手動で更新する必要性を嫌っていました。

次に、新しいMagento Optimizer拡張機能をインストールしました。このモジュールは、このプロセスを自動化します。無効化された/すべてのキャッシュタイプを更新するか、指定された頻度でMagentoキャッシュストレージをフラッシュします。それは私たちのチーム全員にとって本当に安心でした！

この拡張機能のもう1つの優れた機能は、X日より古いセッションファイルとエラーレポートを消去することです。var / sessionおよびvar / reportディレクトリのサイズがギガバイトに成長し、これらのファイルの数が100を超える可能性があることは誰もが知っています。そこで、ウェブサイトのパフォーマンスを低下させるために、Magento Optimizerを一度設定し、これらのディレクトリの定期的な更新を忘れました。

Magentoは、顧客がログインしようとしたときに、放棄されたカートを現在のカートにマージすることで知られています。顧客の経験とロイヤリティの観点からすると、破壊的です。Magento Optimizerモジュールは、X日以上経過した放棄されたカートを自動的に削除します。この機能は販売時にも使用でき、既存の放棄されたカートの時間を制限できます。