Nous exécutons Magento 1.9.2.1 avec Lesti_Fpc sur un serveur géré de taille adéquate. Au départ, nous avons utilisé le cache de fichiers par défaut, ce qui était bien. Mais après que le catalogue ait grandi (bien que je pense que ~ 8000 produits ne soient pas trop mauvais) et que les robots sont devenus plus agressifs, le site est devenu lent dès que le cache devenait un peu plus gros. Lorsque le cache a été vidé, tout fonctionnait à nouveau rapidement.
Nous avons essayé de passer à APC en tant que backend de cache via l'entrée suivante dans le fichier local.xml:
<global>
<cache>
<backend>apc</backend>
<prefix>MYSHOP_</prefix>
</cache>
</global>
Mais cela a encore aggravé les problèmes. J'ai ensuite lu que Cm_Cache_Backend_File est fait pour ce problème et l' ai intégré via:
<global>
<cache>
<backend>Cm_Cache_Backend_File</backend>
</cache>
</global>
Cela semble un peu mieux, mais le problème est toujours le même. Pour garder le cache petit et bien rangé, j'ai également intégré Aoe_CacheCleaner , mais cela n'aide pas non plus. Pourtant, dès que le cache est effacé, tout fonctionne à nouveau rapidement.
EDIT:
Sur la base de la réponse de infabo, j'ai également activé Cm_Cache_Backend_File
pour le FPC avec le fichier app/etc/fpc.xml
et le contenu suivant:
<?xml version="1.0"?>
<config>
<global>
<fpc>
<lifetime>86400</lifetime>
<backend>Cm_Cache_Backend_File</backend>
</fpc>
</global>
</config>
Je suis sûr que cela a du sens, mais cela ne résout pas non plus le problème.
Je sais que la solution générale à ce problème semble être Redis (ou peut-être alternativement Memcached) en tant que backend de cache, mais malheureusement, il n'est pas disponible sur notre serveur géré. Passer à une autre société d'hébergement n'est pas (encore) une option.
J'ai beaucoup enquêté maintenant, mais je n'ai plus d'idée. Peut-être que quelqu'un d'autre peut aider?
la source
Réponses:
J'ai enquêté encore plus et je pense avoir finalement résolu le problème. Alors, que pouvez-vous faire pour analyser un tel problème?
Afin d'avoir une bonne idée lorsque le cache devient trop volumineux et si le problème est vraiment la taille du cache, ajoutez un cronjob qui appelle le script suivant par exemple toutes les 15 minutes:
Ensuite, vous pouvez analyser le contenu de
/html/cache_log
pour voir comment la taille du cache se développe, lorsque votre page devient trop lente et si la cause principale est vraiment le cache.Analysez vos fichiers cache. Par conséquent, il est très utile d'écrire tous les fichiers de cache dans un fichier journal avec par exemple:
Jetez un œil à ce fichier et aux noms de fichiers qu'il contient. Quel type de fichiers cache existe-t-il? Y a-t-il quelque chose de suspect? Dans mon cas, il y avait beaucoup de fichiers de cache contenant
AMSHOPBY
dans leur nom de fichier - une référence à l'extension Amasty Improved Navigation (Amasty_Shopby
). Cela créait beaucoup de fichiers de cache. Certains me paraissaient assez étranges. La désactivation du cache de navigation améliorée d'Amasty a résolu le problème instantanément. J'ai contacté leur support avec une description détaillée et le support était vraiment bon. La stratégie de mise en cache a été rapidement complètement révisée et est maintenant bien meilleure. Ils ont promis d'intégrer le correctif dans la prochaine version de l'extension, donc chaque version> 2.8.3 devrait convenir.Bonne chance pour trouver la cause première de votre grande cache!
la source
Avez-vous également essayé Cm_Cache_Backend_File en tant que backend dans fpc.xml? Essayez peut-être. Je donnerais aussi une chance à Aoe_Profiler. Si vous êtes capable de reproduire les "ralentissements" sur une copie intermédiaire, allez y profiler vos requêtes lentes. Sinon, vous pouvez le faire en production ( je ne le recommande absolument pas , mais si vous osez, vous pouvez configurer le profileur pour qu'il soit simplement activé lorsque le paramètre GET est défini et continuez)
la source
fpc.xml
). Idée intéressante, va essayer, merci!