Мы запускаем Magento 1.9.2.1 с Lesti_Fpc на управляемом сервере соответствующего размера. Изначально мы использовали файловый кеш по умолчанию, что было хорошо. Но после того, как каталог вырос (хотя я думаю, что ~ 8000 продуктов - это не так уж плохо), и сканеры стали более агрессивными, сайт стал медленным, как только кэш стал немного больше. Когда кеш был очищен, все снова работало быстро.
Мы попытались переключиться на APC в качестве серверной части кеша с помощью следующей записи в local.xml:
<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
для FPC с файлом app/etc/fpc.xml
и следующим содержанием:
<?xml version="1.0"?>
<config>
<global>
<fpc>
<lifetime>86400</lifetime>
<backend>Cm_Cache_Backend_File</backend>
</fpc>
</global>
</config>
Я уверен, что это имеет смысл, но это также не решает проблему.
Я знаю, что общим решением этой проблемы является Redis (или, возможно, Memcached) в качестве бэкэнда кеша, но, к сожалению, он недоступен на нашем управляемом сервере. Переключение на другую хостинговую компанию не является (пока) вариантом.
Я много исследовал сейчас, но у меня больше нет идей. Может кто-нибудь еще может помочь?
источник
Ответы:
Я исследовал еще больше, и я думаю, что наконец решил проблему. Итак, что вы можете сделать, чтобы проанализировать такую проблему?
Чтобы иметь хорошее представление о том, когда кэш становится слишком большим и если проблема действительно в размере кеша, добавьте cronjob, который вызывает следующий скрипт, например, каждые 15 минут:
Затем вы можете проанализировать содержимое,
/html/cache_log
чтобы увидеть, как развивается размер кеша, когда ваша страница становится слишком медленной и если основной причиной является кеш.Проанализируйте ваши файлы кеша. Поэтому весьма полезно записать все файлы кэша в файл журнала, например, с помощью:
Посмотрите на этот файл и имена файлов внутри. Какие файлы кеша есть? Есть ли что-нибудь подозрительное? В моем случае было очень много файлов кэша, содержащих
AMSHOPBY
в имени файла - ссылку на расширение Amasty Improved Navigation (Amasty_Shopby
). Он создавал множество файлов кеша. Некоторые из них выглядели довольно странно для меня. Отключение кеша Amasty Improved Navigation решило проблему мгновенно. Я связался с их поддержкой с подробным описанием, и поддержка была действительно хорошей. Стратегия кэширования была быстро полностью пересмотрена и теперь стала намного лучше. Они обещали интегрировать патч в следующую версию расширения, поэтому все версии> 2.8.3 должны быть в порядке.Удачи в поиске первопричины вашего большого кэша!
источник
Вы пробовали Cm_Cache_Backend_File как бэкэнд в fpc.xml? Может быть, попробовать. Я бы тоже дал Aoe_Profiler шанс. Если вы в состоянии воспроизвести «замедления» на промежуточной копии - зайдите и профилируйте свои медленные запросы там. В противном случае вы можете сделать это на производстве ( я строго не рекомендую это делать , но если вы решитесь, вы можете настроить профилировщик так, чтобы он был включен только тогда, когда задан параметр GET, и продолжайте)
источник
fpc.xml
). Интересная идея, попробую, спасибо!