Magento Cache - путаница с Varnish, Redis, APC, Memcache

Я пытаюсь улучшить выступления Magento (рано или поздно "MageDev" попал в эту точку :)

Я провел небольшое исследование и нашел много хороших, но не однородных руководств.

Что я получил, так это:

• MemCache или Redis являются общей системой кеширования, они кешируют данные и могут быть интегрированы непосредственно с Magento ( local.xml ).
• APC - это кеш для самого php-кода, который может быть интегрирован только на уровне сервера.
• Varnish - это обратный прокси, он кеширует ответы, которые могут быть интегрированы только на уровне сервера. (есть расширение для Magento, скипидар, но я не уверен, что именно делает)

После всего этого хорошего прочтения я все еще немного озадачен тем, что из перечисленных выше систем кеширования можно использовать в комбинациях для EX:

• MemCache + APC?
• Redis + APC?
• я могу добавить Varnish к одной из вышеуказанных конфигураций?

Просто чтобы прояснить вопрос не о том, как настроить Magento или сервер, а о том, какие возможности допускаются, и о том, как смешивать системы кеша. (кроме того, если кто-то может прийти с хорошей рекомендацией, я был бы признателен, спасибо.)

TL; DR - В MageStack мы используем Varnish, Redis (кеш), Redis (сеансы) и Eaccelerator / Zend OPCache (в зависимости от версии PHP)

Вы уже многое поняли.

Бэкэнд кеша, хранилище сеансов, кэш опкодов, кеширование полной страницы и кеш обратного прокси полностью различны.

Вы можете использовать разные технологии для всех, и вы можете использовать их ВСЕ одновременно (включая Varnish и FPC)

Cache Backends

• Файлы (ядро) по умолчанию
• Memcache (ядро)
• APC (основной)
• Redis (<1.9 модуль любезно предоставлен Colin Mollenhour)
• MongoDB (модуль любезно предоставлен Colin Mollenhour)
• Рубик (модуль любезно предоставлен Дэниелом Слоофом)

Вы можете использовать только один кеш-сервер.

Вопреки распространенному мнению, использование кэша на основе памяти не приведет к повышению производительности. Но это преодолеет некоторые фатальные недостатки в кэшировании файлов по умолчанию в Magento.

На момент написания этого сообщения Redis - моя рекомендация.

Сессионные магазины

• Файлы (ядро) по умолчанию
• Memcache (ядро)
• Redis (<1.9 модуль любезно предоставлен Colin Mollenhour)
• MongoDB (модуль любезно предоставлен Colin Mollenhour)

Вы можете использовать только одно хранилище сеансов.

Вопреки распространенному мнению, использование хранилища сессий на основе памяти не улучшит производительность.

На момент написания этого сообщения Redis - моя рекомендация.

Кэш OpCode

• APC
• XCache
• Eaccelerator (PHP <5.4)
• Zend OPCache (PHP> 5.4)

На самом деле вы можете установить несколько кэшей кода операции, но это не рекомендуется, и я не ожидаю увидеть никаких преимуществ.

Мои рекомендации в скобках выше.

Для этого не требуется устанавливать модуль.

Обратный прокси-кэш

• лакировка
• Nginx
• апаш
• ... и многое другое

Вы можете использовать несколько обратных прокси-серверов, и хотя это сложно и склонно к удлинению кэша, оно может иметь свои преимущества (т. Е. Предотвращать штамповку во время очистки кэша).

Используйте один, когда это необходимо (т. Е. Не для ускорения медленного сайта, а для сокращения использования ресурсов на быстром сайте).

Чтобы использовать обратный прокси-сервер, ему нужно включить и серверную часть, и модуль Magento.

Причина для модуля состоит в том, чтобы помочь контролировать логику кэширования (т. Е. Сообщить кешу, что он должен и не должен кешировать), а также управлять содержимым кеша (т. Е. Запускать очистку кеша).

Я не рекомендую ничего, если у вас нет полного понимания того, что вы делаете. Плохо настроенные обратные прокси-серверы могут сломать информацию заголовка, могут вызвать потерю сеанса, совместное использование сеанса, устаревшее содержимое, применить дополнительные ограничения для времени / буферов загрузки, потреблять дополнительные ресурсы и т. Д.

Кэш полной страницы

• EE FPC
• ... много других (через модули)

Используйте один, когда это необходимо (т. Е. Не для ускорения медленного сайта, а для сокращения использования ресурсов на быстром сайте).

Вопреки распространенному мнению, вы можете (и должны) использовать FPC в сочетании с обратным прокси-кэшем. Они решают разные проблемы и имеют разные возможности.

FPC могут использовать больше интеллекта, потому что они имеют прямой доступ к сеансу пользователей и ядру Magento, тогда как обратный прокси-сервер не осведомлен о приложении (он довольно тупой в своей работе) - поэтому они дополняют друг друга, а не конкурируют друг с другом ,

То есть. Не думай о Лаке или FPC, думай о Лаке и FPC.

Я бы пошел на Redis + APC с лаком на вершине.

«Почему Redis», спросите вы? Прочитайте этот превосходный ответ . Redis в основном заменяет стандартную файловую систему кэширования Magento. Поскольку Redis быстрее, он даст вам некоторое улучшение скорости.

Лак на самом деле не имеет ничего общего с внутренней работой. Он помещается сверху и кэширует статический контент, поэтому он никогда не достигает Magento как запрос. За исключением отверстия перфорированной части, которая есть.

В то время как Varnish просто фокусируется на кэшировании внешнего интерфейса, Redis также ускоряет другие типы кэша, такие как EAV и конфигурационные кэши.

При желании вы можете проверить некоторые расширения Full Page Cache для Magento вместо Varnish. Хотя это не так быстро, как правило, проще в реализации и не зависит от дополнительного программного обеспечения (например, Varnish)