Magento Automatic Caching Insight

Мы работаем с 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 утра.

• Как лучше всего подойти к этой ситуации? Как вы понимаете, восстановление кеша в гигабайтах каждый день просто недопустимо.

У вас недостаточно оперативной памяти

У нас есть около 240k продуктов
Доступные оперативной памяти : 6GB
Темы: 32

У вас недостаточно оперативной памяти для количества продуктов, которые у вас есть. Как правило, мы рекомендуем по крайней мере 2-4 ГБ ОЗУ на логическое ядро.

Если вы наметите свое возможное использование памяти:

• 64 max_memoryпотока PHP с размером ~ 768 МБ = 24 ГБ
• 240 000 продуктов, вероятно, будут означать около 15 ГБ табличного пространства InnoDB
• 64 потока PHP гарантируют около 128 подключений MySQL, как правило, это обходится в 200 МБ на соединение минимум
• Внутреннее хранилище для 240 000 продуктов в Redis И 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, чтобы оно выполняло именно то, что вам нужно.

Вот быстрый патч, чтобы дать вам представление о том, как решить вашу проблему.

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

Не бегите гусеничным

Если у вас достаточно приличный шаг - мы не советуем запускать инструмент сканирования, он генерирует ненужную нагрузку. Люди / боты / сканеры, просматривающие сайт, должны держать кэш заполненным.

Но чтобы ответить на ваш вопрос, если вы посмотрите в файле конфигурации, упомянутом выше, - вы увидите расписание cron, которое было определено для окна просмотра сканирования.

Если вы можете позволить себе несвежий контент

И в конечном итоге, если у вас достаточно оперативной памяти. Вы могли бы выиграть от увеличения TTL контента, хранящегося в FPC - чтобы сохранить ваши кешированные данные дольше.

В <full_page_cache>теге у вас ./app/etc/local.xmlпросто определите

<lifetimelimit>86400</lifetimelimit>

Время жизни определяется в секундах. Вам необходимо найти баланс между свежестью контента, производительностью и объемом доступного пространства для хранения.

Почему вы используете стороннее расширение для кэширования с EE?

Вы платите премию за FPC - что мне больно говорить, это очень хорошо. Так почему же вы используете сторонние альтернативы? Убери это.

Скажи это так. Если ваша машина работала плохо - вы бы просто добавили другой двигатель в багажник для компенсации; или просто починить двигатель уже там?

Мы вас очень хорошо понимаем! Мы добавляем новые или меняем наши продукты каждый день, а также модифицируем статические блоки. Таким образом, мы были заполнены недействительным кэшем Magento, и эта константа перешла в System -> Cache Management. Мы ненавидели необходимость обновлять недействительные типы кэша вручную.

Затем мы установили новое расширение Magento Optimizer . Этот модуль автоматизирует этот процесс. Он обновляет недействительные / все типы кешей или сбрасывает хранилище кеша Magento с указанной частотой. Это было настоящим облегчением для всей нашей команды!

Еще одна замечательная особенность этого расширения заключается в том, что оно очищает файлы сеансов и отчеты об ошибках старше X дней. Всем известно, что размер каталогов var / session и var / report может вырасти в гигабайты, а количество этих файлов может превысить сотню. Поэтому, чтобы замедлить работу сайта, мы однажды установили Оптимизатор Magento и забыли о периодическом обновлении этих каталогов.

Magento известен тем, что объединяет заброшенную корзину с текущей, когда клиенты пытаются войти в систему. С точки зрения опыта и лояльности клиентов, это деструктивно. Модуль Magento Optimizer автоматически удаляет брошенные корзины старше X дней. Вы также можете использовать эту функцию во время продажи и ограничить время для оставленных корзин.