キャッシュが「フル」の場合、Magentoが非常に遅くなる

適切なサイズの管理対象サーバー上で、Magento 1.9.2.1とLesti_Fpcを実行しています。最初は、デフォルトのファイルキャッシュを使用していましたが、問題ありませんでした。しかし、カタログが大きくなり（約8000製品は悪くないと思いますが）、クローラーがより積極的になると、キャッシュが少し大きくなるとすぐにサイトが遅くなりました。キャッシュがクリアされたとき、すべてが再び迅速に実行されていました。

local.xmlの次のエントリを使用して、キャッシュバックエンドとしてAPCに切り替えようとしました。

<global>
    <cache>
        <backend>apc</backend>
        <prefix>MYSHOP_</prefix>
    </cache>
</global>

しかし、これは問題をさらに悪化させました。次に、Cm_Cache_Backend_Fileがこの問題のために作成され、次のように統合したことを読みます。

<global>
    <cache>
        <backend>Cm_Cache_Backend_File</backend>
    </cache>
</global>

これは少し良い感じですが、問題は同じです。キャッシュを小さく整理するために、Aoe_CacheCleanerも統合しましたが、これも役に立ちません。それでも、キャッシュがクリアされるとすぐに、すべてが再び迅速に実行されます。

編集：
infaboの回答に基づいCm_Cache_Backend_Fileて、ファイルapp/etc/fpc.xmlと次のコンテンツでFPCをアクティブ化しました：

<?xml version="1.0"?>
<config>
    <global>
        <fpc>
            <lifetime>86400</lifetime>
            <backend>Cm_Cache_Backend_File</backend>
        </fpc>
    </global>
</config>

これは理にかなっていると確信していますが、問題を解決することもできません。

この問題の一般的な解決策は、キャッシュバックエンドとしてのRedis（または多分Memcached）であるようですが、残念ながら、管理対象サーバーでは使用できません。別のホスティング会社に切り替えることは（まだ）オプションではありません。

今は色々調べましたが、もうわかりません。多分誰かが助けることができますか？

さらに調査したところ、ようやく問題は解決したと思います。では、このような問題を分析するにはどうすればよいでしょうか。

1. キャッシュが大きくなりすぎて問題が実際にキャッシュサイズである場合は、次のスクリプトを呼び出すcronjobを追加します（例：15分ごと）。

   #!/bin/bash
   
   # this script is an attempt to check if the full cache is the real performance problem
   # it should be called regularly as a cronjob
   
   cache_dir="/html/shop/var/cache/"
   log_file="/html/cache_log"
   
   line=$(date)
   line="$line Size of cache directory: $(du -hs $cache_dir)"
   echo "$line" >> $log_file
   
   line=$(date)
   line="$line Total cache tags: $(find $cache_dir'cm-tags/' -type f | wc -l)"
   echo "$line" >> $log_file
   

   次に、のコンテンツを分析して/html/cache_log、キャッシュサイズがどのように変化するか、ページが遅くなりすぎた場合、および根本的な原因が実際にキャッシュであるかどうかを確認できます。

2. キャッシュファイルを分析します。したがって、たとえば次のようにして、すべてのキャッシュファイルをログファイルに書き込むと非常に便利です。

   ls -R /html/shop/var/cache > /html/cachefiles

   このファイルとその中のファイル名を見てください。どんな種類のキャッシュファイルがありますか？疑わしいことはありますか？私の場合、AMSHOPBYファイル名にAmasty Improvement Navigation（Amasty_Shopby）拡張への参照が含まれているキャッシュファイルがたくさんありました。大量のキャッシュファイルが作成されていました。それらのいくつかは私にはかなり奇妙に見えました。Amastyの改善されたナビゲーションキャッシュを無効にすると、問題はすぐに解決しました。私は彼らのサポートに詳細な説明を連絡しましたが、サポートは本当に良かったです。キャッシング戦略はすぐに完全に見直され、現在ははるかに優れています。彼らは、パッチを拡張機能の次のバージョンに統合することを約束したため、2.8.3を超えるすべてのバージョンで問題ないはずです。

大きなキャッシュの根本的な原因を見つけるのに頑張ってください！

fm.xmlのバックエンドとしてCm_Cache_Backend_Fileも試しましたか？多分それを試してみてください。私もAoe_Profilerを試してみます。ステージングコピーで「スローダウン」を再現できる場合は、低速のリクエストをそこにプロファイルしてください。それ以外の場合は、本番環境で実行できます（厳密にはお勧めしませんが、勇気がある場合は、GETパラメーターが設定されているときにプロファイラーを有効にするように構成して、先に進むことができます）。