Мы работаем с Magento EE 1.11 с memcache. 2 ГБ на сервер Memcahce, всего 4 ГБ. У нас есть около 240 тыс. Продуктов.
- Доступный оперативной памяти: 6 ГБ
- Ядер: 16
- Темы: 32
Это соглашение, добавляется больше новых продуктов, и изменения в продуктах происходят ежедневно, и, конечно, каждый раз, когда в бэкэнд добавляется / модифицируется новый продукт, кэш становится недействительным, в частности, «Кэш полной страницы».
Когда включена функция Magentos Auto Cache Generation, на создание кеша уходит около 2 дней, при этом искатель выделяет 8 потоков. Через 2 дня memcache плавает примерно на 2 ГБ, разделенных между двумя RAM-дисками.
Проблема заключается в том, что при ежедневном изменении продуктов кэш-память становится недействительной, и как только «Кэш полной страницы» обновляется, эти 2 ГБ кэш-памяти возвращаются в исходное положение, равное 0, и вязкий цикл кеша Magentos Auto начинается снова. Теперь кэш не только возвращается к 0, но и загрузка процессора возрастает до 90%, а веб-сайт превращается в игру ожидания 5-10+ секунд, и вы можете просто забыть о попытке запросить продукт с более чем 100 вариантами, если он без кеширования загрузка в первый раз займет минуты, это смешно.
Итак, мои вопросы к сообществу.
- Есть ли способ для Magento автоматически «обновлять» кеш в случае его аннулирования, не перестраивая весь кеш и начиная с 0? Я знаю, когда кеш становится недействительным, что Magento знает, что что-то изменилось, но не точно, где в кеше (поправьте меня, если я ошибаюсь). Существуют ли модули / конфигурации для обхода восстановления всего кэша?
С другой стороны, мы используем модуль Tiny Bricks LightSpeed.
Может ли Magentos Automatic Cache Generation контролироваться по времени с помощью cronjob? Скажем, начинать ползать с 10 вечера - 6 утра.
Как лучше всего подойти к этой ситуации? Как вы понимаете, восстановление кеша в гигабайтах каждый день просто недопустимо.
Ответы:
У вас недостаточно оперативной памяти
У вас недостаточно оперативной памяти для количества продуктов, которые у вас есть. Как правило, мы рекомендуем по крайней мере 2-4 ГБ ОЗУ на логическое ядро.
Если вы наметите свое возможное использование памяти:
max_memory
потока PHP с размером ~ 768 МБ = 24 ГБlzf
сжатых - все равно будет занимать около 6 ГБ ОЗУТаким образом, общее количество выделенной оперативной памяти составляет 70 ГБ - мы даже не упомянули ОС и т. Д.
Ваше оборудование ужасно занижено . Я бы посоветовал прочитать статью о настройке этого сервера Magento, чтобы узнать, как продвигаться.
Memcached не поддерживает кеш-теги
Если вы используете Memcached (не проблема, это очень высокая производительность), то вы либо храните кеш-теги, либо нет. Если у вас нет
slow_backend
определенного - тогда вы не сохраняете теги, что в основном означает, что ваш кэш не может различить какие-либо типы кэша - поэтому вы не сможете сбросить их независимо.Прочитайте это, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/
Мы настоятельно рекомендуем перейти на Redis. У него есть свои причуды и он нуждается в значительной доработке для крупных магазинов. Но в целом производительность будет немного лучше, чем у Memcached с реальным преимуществом поддержки кеш-тегов.
404 и FPC
У FPC есть реальная проблема, фактически, у всех движков кэширования есть проблема с 404-ми. Причина в том, что любые старые URL-адреса, по-прежнему сканируемые или на которые ссылаются, попадут на страницу, которая должна перебирать всю
core_url_rewrite
таблицу, пытаться найти совпадение со всеми определенными маршрутизаторами и пространствами имен, прежде чем, наконец, отказаться и загрузить 404.Затем кэшируйте ресурс, который не имеет значения и будет занимать место в вашем хранилище. Вы, вероятно, обнаружите, что огромная доля вашего хранилища Memcached фактически съедается 404 контентом.
С большими каталогами (240 тыс. Товаров) вы наверняка получите свою справедливую долю товарооборота и, следовательно, изменения в URL-адресах, а впоследствии и многие 404-е.
FPC Invalidate vs. Clean
На данный момент - и по умолчанию - поведение FPC заключается в том, чтобы очистить кэш от изменений, а не просто сделать недействительной запись в кэше. Мы написали расширение для изменения этого поведения магазина EE, чтобы оно выполняло именно то, что вам нужно.
Вот быстрый патч, чтобы дать вам представление о том, как решить вашу проблему.
Не бегите гусеничным
Если у вас достаточно приличный шаг - мы не советуем запускать инструмент сканирования, он генерирует ненужную нагрузку. Люди / боты / сканеры, просматривающие сайт, должны держать кэш заполненным.
Но чтобы ответить на ваш вопрос, если вы посмотрите в файле конфигурации, упомянутом выше, - вы увидите расписание cron, которое было определено для окна просмотра сканирования.
Если вы можете позволить себе несвежий контент
И в конечном итоге, если у вас достаточно оперативной памяти. Вы могли бы выиграть от увеличения TTL контента, хранящегося в FPC - чтобы сохранить ваши кешированные данные дольше.
В
<full_page_cache>
теге у вас./app/etc/local.xml
просто определитеВремя жизни определяется в секундах. Вам необходимо найти баланс между свежестью контента, производительностью и объемом доступного пространства для хранения.
Почему вы используете стороннее расширение для кэширования с EE?
Вы платите премию за FPC - что мне больно говорить, это очень хорошо. Так почему же вы используете сторонние альтернативы? Убери это.
Скажи это так. Если ваша машина работала плохо - вы бы просто добавили другой двигатель в багажник для компенсации; или просто починить двигатель уже там?
источник
Мы вас очень хорошо понимаем! Мы добавляем новые или меняем наши продукты каждый день, а также модифицируем статические блоки. Таким образом, мы были заполнены недействительным кэшем Magento, и эта константа перешла в System -> Cache Management. Мы ненавидели необходимость обновлять недействительные типы кэша вручную.
Затем мы установили новое расширение Magento Optimizer . Этот модуль автоматизирует этот процесс. Он обновляет недействительные / все типы кешей или сбрасывает хранилище кеша Magento с указанной частотой. Это было настоящим облегчением для всей нашей команды!
Еще одна замечательная особенность этого расширения заключается в том, что оно очищает файлы сеансов и отчеты об ошибках старше X дней. Всем известно, что размер каталогов var / session и var / report может вырасти в гигабайты, а количество этих файлов может превысить сотню. Поэтому, чтобы замедлить работу сайта, мы однажды установили Оптимизатор Magento и забыли о периодическом обновлении этих каталогов.
Magento известен тем, что объединяет заброшенную корзину с текущей, когда клиенты пытаются войти в систему. С точки зрения опыта и лояльности клиентов, это деструктивно. Модуль Magento Optimizer автоматически удаляет брошенные корзины старше X дней. Вы также можете использовать эту функцию во время продажи и ограничить время для оставленных корзин.
источник