Magento Automatic Caching Insight

16

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

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

Олег
источник
1
Я чувствую себя так глупо сейчас, я должен был опубликовать более подробную информацию о сервере. Я только что познакомился с настройкой сервера, когда задал вопрос. Но вот фактическая настройка: 2 сервера, идентичные. Один под управлением Apache, один MySQL, оба с 64 ГБ оперативной памяти, расположенные на двух процессорах AMD Opteron 6276 с 32 ядрами и 32 потоками. После долгих и долгих чтений я покопался в конфигурации сервера и понял, что многие вещи были неправильно настроены, особенно кеш Magentos. Они настроили 2 ГБ APC в качестве бэкенда и 4 ГБ memcache для медленного бэкенда в конфигурации 1 + 1 и кучу других странных конфигураций.
Олег
Возможно, потому что, когда был сделан переход на EE, размер каталога был намного меньше, не уверен. Плюс, я все еще не уверен, как настроен сервер sql, потому что я еще не запрашивал доступ. Так что я уверен, что это еще одна загадка. Я просто хотел поблагодарить вас, Сонасси, за то, что вы нашли время ответить и за то, что предоставили отличные идеи и указатели, каждый помогает!
Олег
Для тех, кто сталкивается с этой темой, здесь очень полезны ссылки для настройки кэша Magentos: magebase.com/magento-tutorials/improving-the-file-cache-backend и especialy *** -> nbs-system.co.uk/ blog-2 / magento-оптимизация-howto-en.html плюс обязательно прочитайте Magento Wiki и Magento White Pages.
Олег

Ответы:

14

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

У нас есть около 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 - что мне больно говорить, это очень хорошо. Так почему же вы используете сторонние альтернативы? Убери это.

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

Бен Лессани - Сонасси
источник
-1

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

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

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

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

Джеймс
источник
1
Джеймс, у тебя есть связь с этим модулем? Вы, кажется, в восторге от этого.
Пархамр