Magento 自動キャッシュインサイト

https://magento.stackexchange.com/questions/610

16-10-2019
|

質問

Magento EE 1.11 を memcache で実行しています。memcahce サーバーあたり 2GB、合計 4GB。約24万点の商品を取り揃えております。

利用可能なラム:6GB
コア:16
スレッド:32

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

Magentos 自動キャッシュ生成が有効になっている場合、8 つのスレッドがクローラーに割り当てられ、キャッシュの構築に約 2 日かかります。2 日後、memcache は 2 つの RAM ディスク間で約 2 GB 離れた状態で浮遊します。

問題は、製品が毎日変更されるとキャッシュが無効になり、「フルページキャッシュ」が更新されるとすぐに 2GB のキャッシュが振り出しの 0 に戻り、Magentos Auto キャッシュの粘性サイクルが再び開始されることです。これで、キャッシュが 0 に戻っただけでなく、CPU 使用率が 90% に急増し、Web サイトは 5 ～ 10 秒以上待つゲームに変わり、100 を超えるバリエーションがある商品をリクエストしようとすることを忘れることができます。キャッシュされていないと、最初にロードするのに数分かかりますが、それはばかげています。

そこで、コミュニティへの質問です。

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

余談ですが、Tiny Bricks LightSpeed モジュールを使用しています。

Magentos の自動キャッシュ生成は cronjob で時間制御できますか?たとえば、午後 10 時から午前 6 時までにクロールを開始するとします。
この状況に対処する最善の方法は何でしょうか? ご存知のとおり、毎日ギガバイト単位のキャッシュを再構築することは容認できません。

解決

RAM がほとんど足りません

約24万点の商品を取り揃えております
利用可能なラム:6GB
スレッド:32

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

考えられるメモリ使用量を計画すると、次のようになります。

64 個の PHP スレッド max_memory ～768MB = 24GB
240,000 の製品は、おそらく約 15 GB の InnoDB テーブルスペースを意味します。
64 個の PHP スレッドでは、約 128 個の MySQL 接続が保証されます。通常、これには最低接続ごとに約 200MB のコストがかかります
Redis での 240,000 製品のバックエンドストレージおよび lzf 圧縮 - それでも約 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 コンテンツによって消費されていることがわかるでしょう。

大規模なカタログ (240,000 製品) では、製品の売上高の相当な割合が確実に発生し、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 スケジュールがわかります。

古いコンテンツを許容できる場合

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

の中に <full_page_cache> あなたのタグ ./app/etc/local.xml ただ定義するだけ

<lifetimelimit>86400</lifetimelimit>

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

EE でサードパーティのキャッシュ拡張機能を使用しているのはなぜですか

FPC に割増料金を支払っているのですが、これは非常に良いことだと言うのは心苦しいです。では、なぜサードパーティの代替手段を過剰に実行するのでしょうか。 それを除く。

このように置いてください。車の調子が悪かった場合、それを補うためにトランクに別のエンジンを追加するだけで済みますか。それともすでに搭載されているエンジンを修理するだけですか？

他のヒント

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

次に、NEWをインストールしました Magento Optimizer Extension. 。このモジュールはこのプロセスを自動化します。無効化/すべてのキャッシュタイプをリフレッシュするか、指定された周波数でMagentoキャッシュストレージをフラッシュします。それは私たちのすべてのチームにとって本当に安心でした！

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

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

ライセンス： CC-BY-SA と帰属

所属していません magento.stackexchange

Magento 自動キャッシュ インサイト