Magento extrem langsam, wenn der Cache "voll" ist

Wir führen Magento 1.9.2.1 mit Lesti_Fpc auf einem ausreichend großen verwalteten Server aus. Anfangs haben wir den Standard-Datei-Cache verwendet, was in Ordnung war. Aber nachdem der Katalog gewachsen war (obwohl ich denke, dass ~ 8000 Produkte nicht schlecht sind) und Crawler aggressiver wurden, wurde die Site langsam, sobald der Cache etwas größer wurde. Als der Cache geleert wurde, lief alles wieder schnell.

Wir haben versucht, über den folgenden Eintrag in der Datei local.xml als Cache-Backend zu APC zu wechseln:

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

Dies machte die Probleme jedoch noch schlimmer. Ich habe dann gelesen, dass Cm_Cache_Backend_File für dieses Problem erstellt wurde und es integriert über:

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

Das fühlt sich ein bisschen besser an, aber das Problem ist immer noch dasselbe. Um den Cache klein und ordentlich zu halten, habe ich auch Aoe_CacheCleaner integriert , aber das hilft auch nicht. Sobald der Cache geleert ist, läuft alles wieder schnell.

EDIT:
Basierend auf der Antwort von infabo habe ich auch Cm_Cache_Backend_Filefür die FPC mit der Datei app/etc/fpc.xmlund dem folgenden Inhalt aktiviert :

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

Ich bin sicher, dass dies sinnvoll ist, aber es löst auch nicht das Problem.

Ich weiß, dass die allgemeine Lösung für dieses Problem Redis (oder alternativ Memcached) als Cache-Backend zu sein scheint, aber leider ist es auf unserem verwalteten Server nicht verfügbar. Ein Wechsel zu einem anderen Hosting-Unternehmen ist (noch) keine Option.

Ich habe jetzt viel recherchiert, aber ich habe keine Ahnung mehr. Vielleicht kann noch jemand helfen?

Ich habe noch mehr nachgeforscht und ich denke, ich habe das Problem endlich gelöst. Was können Sie also tun, um ein solches Problem zu analysieren?

1. Um eine gute Vorstellung davon zu haben, wann der Cache zu groß wird und ob das Problem tatsächlich die Cache-Größe ist, fügen Sie einen Cronjob hinzu, der das folgende Skript aufruft, z. B. alle 15 Minuten:

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

   Anschließend können Sie den Inhalt von analysieren, um festzustellen /html/cache_log, wie sich die Cache-Größe entwickelt, wann Ihre Seite zu langsam wird und ob die Hauptursache wirklich der Cache ist.

2. Analysieren Sie Ihre Cache-Dateien. Daher ist es sehr hilfreich, alle Cache-Dateien in eine Protokolldatei zu schreiben, z.

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

   Schauen Sie sich diese Datei und die darin enthaltenen Dateinamen an. Welche Art von Cache-Dateien gibt es? Gibt es etwas Verdächtiges? In meinem Fall gab es eine ganze Reihe von Cache-Dateien, die AMSHOPBYihren Dateinamen enthielten - ein Verweis auf die Amasty_ShopbyErweiterung Amasty Improved Navigation ( ). Es wurden viele Cache-Dateien erstellt. Einige von ihnen sahen für mich ziemlich komisch aus. Durch Deaktivieren des Amasty Improved Navigation-Cache wurde das Problem sofort behoben. Ich kontaktierte den Support mit einer detaillierten Beschreibung und der Support war wirklich gut. Die Caching-Strategie wurde schnell komplett überarbeitet und ist jetzt viel besser. Sie versprachen, den Patch in die nächste Version der Erweiterung zu integrieren, daher sollte jede Version> 2.8.3 in Ordnung sein.

Viel Glück beim Finden der Grundursache für Ihren großen Cache!

Haben Sie Cm_Cache_Backend_File auch als Backend in fpc.xml ausprobiert? Vielleicht versuchen Sie es mal. Ich würde Aoe_Profiler auch eine Chance geben. Wenn Sie in der Lage sind, die "Verlangsamungen" auf einer Staging-Kopie zu reproduzieren, gehen Sie und profilieren Sie Ihre langsamen Anforderungen dort. Andernfalls können Sie dies in der Produktion tun ( ich empfehle es strikt nicht , aber wenn Sie sich trauen, können Sie den Profiler so konfigurieren, dass er nur aktiviert wird, wenn der GET-Parameter festgelegt ist, und fortfahren).