Magento extremamente lento quando o cache está “cheio”

Estamos executando o Magento 1.9.2.1 com Lesti_Fpc em um servidor gerenciado de tamanho adequado. Inicialmente, usamos o cache de arquivos padrão, o que foi bom. Mas depois que o catálogo cresceu (embora eu ache ~ 8000 produtos não muito ruins) e os rastreadores se tornaram mais agressivos, o site ficou lento assim que o cache ficou um pouco maior. Quando o cache foi limpo, tudo estava funcionando rápido novamente.

Tentamos mudar para a APC como um back-end de cache através da seguinte entrada no local.xml:

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

Mas isso tornou os problemas ainda piores. Depois, li que Cm_Cache_Backend_File foi criado para esse problema e o integrei via:

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

Isso parece um pouco melhor, mas o problema ainda é o mesmo. Para manter o cache pequeno e organizado, eu também integrei o Aoe_CacheCleaner , mas isso também não ajuda. Ainda assim, assim que o cache é limpo, tudo volta a funcionar rapidamente.

EDIT:
Com base na resposta de infabo, também ativei Cm_Cache_Backend_Fileo FPC com o arquivo app/etc/fpc.xmle o seguinte conteúdo:

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

Estou certo de que isso faz sentido, mas também não resolve o problema.

Sei que a solução geral para esse problema parece ser o Redis (ou talvez o Memcached) como um back-end de cache, mas, infelizmente, ele não está disponível em nosso servidor gerenciado. Mudar para outra empresa de hospedagem não é (ainda) uma opção.

Investiguei muito agora, mas não tenho mais ideia. Talvez alguém mais possa ajudar?

Investiguei ainda mais e acho que finalmente resolvi o problema. Então, o que você pode fazer para analisar esse problema?

1. Para ter uma boa idéia de quando o cache fica muito grande e se o problema é realmente o tamanho do cache, adicione um cronjob que chame o seguinte script, por exemplo, a cada 15 minutos:

   #!/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
   

   Em seguida, você pode analisar o conteúdo de /html/cache_logpara ver como o tamanho do cache se desenvolve, quando sua página fica muito lenta e se a causa raiz é realmente o cache.

2. Analise seus arquivos de cache. Portanto, é bastante útil gravar todos os arquivos de cache em um arquivo de log com, por exemplo:

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

   Dê uma olhada neste arquivo e nos nomes dos arquivos. Que tipo de arquivos de cache existem? Existe algo suspeito? No meu caso, havia muitos arquivos de cache contendo AMSHOPBYo nome do arquivo - uma referência à extensão Amasty Improved Navigation ( Amasty_Shopby). Ele estava criando muitos arquivos de cache. Alguns deles pareciam bastante estranhos para mim. A desativação do cache do Amasty Improved Navigation resolveu o problema instantaneamente. Entrei em contato com o suporte com uma descrição detalhada e o suporte foi muito bom. A estratégia de armazenamento em cache foi rapidamente revisada completamente e agora é muito melhor. Eles prometeram integrar o patch na próxima versão da extensão, portanto todas as versões> 2.8.3 devem ficar bem.

Boa sorte em encontrar a causa raiz do seu grande cache!

Você já tentou o Cm_Cache_Backend_File como back-end no fpc.xml? Talvez tente. Eu daria uma chance ao Aoe_Profiler também. Se você é capaz de reproduzir as "lentidões" em uma cópia de teste - vá e analise seus pedidos lentos lá. Caso contrário, você poderá fazê-lo na produção ( eu estritamente não o recomendo , mas se você ousar, poderá configurar o criador de perfil para ser ativado apenas quando o parâmetro GET estiver definido e continuar)