Подходит ли вам Varnish?
Varnish - не главное и не окончательное исполнение Magento. Это здорово, чтобы компенсировать нагрузку от ботов и покупателей окон, но это не должно быть вашим первым портом захода, чтобы реально сделать ваш магазин быстрее.
Фактически, реализация Varnish должна стать последним изменением производительности вашего магазина. Вставляйте его только тогда, когда вы видите время загрузки страницы, которое Magento может доставить без него (например, <600 мс времени загрузки страницы).
Ваш магазин все еще должен быть быстрым
Поскольку Varnish по-прежнему требуется загрузка хотя бы одной страницы для заполнения кэша, это означает, что ваша производительность без кэширования все еще должна быть очень хорошей. Подавляющее большинство уникальных URL-адресов (многоуровневые переходы навигации, поисковые запросы и т. Д.) Никогда не будут в действительности обслуживаться из Varnish, если только:
а) Ваши TTL настолько высоки, что поисковый запрос от 4 дней назад все еще действует сегодня
б) Шаг на сайте настолько велик, что URL-адреса заполняются в очень короткий промежуток времени
Вы также должны учитывать, что не каждый магазин поддается Varnish . Любой сайт, который поощряет пользователей создавать личный сеанс (например, вход в систему, добавление в корзину и т. Д.) В начале пути к клиенту, будет означать, что Varnish будет в конечном итоге избыточным.
Например, частные магазины покупок поощряют пользователей входить в систему с самого начала, однако при этом это означает, что Varnish никогда не имеет неуникального контента с возможностью кэширования. Таким образом, ваш рейтинг попаданий будет крайне низким, и использование Varnish не принесет никакой пользы.
Свежий контент или более высокие показатели популярности
Изображение предоставлено magestack.com
Эффективное использование Varnish - это достижение баланса между устаревшим контентом и количеством посетителей вашего сайта.
Если у вас есть занятый сайт - есть вероятность, что вы можете избежать низких TTL и при этом иметь высокий рейтинг популярности Varnish - и при этом продолжать иметь низкие TTL - таким образом, более свежий контент. Таким образом, ваши акции / изменения цен быстро отражаются, и кэш постоянно заполнен объемом шага.
Если у вас есть сайт с низким трафиком - тогда вам придется идти на компромисс. Либо увеличьте свои TTL, чтобы обеспечить более высокий рейтинг попаданий, либо обновите контент. Вы не можете иметь оба. Да, вы можете запускать инструмент сканирования / паука непрерывно - но ресурсы, которые он будет потреблять, а также объем или URL-адреса, которые можно сканировать (обычно в десятках тысяч для небольших магазинов), означает, что он просто не эффективен. Поэтому обычно небольшие магазины получат больше пользы от хорошего расширения FPC и высоко оптимизированной конфигурации сервера.
Но, конечно, я могу использовать Varnish, даже когда пользователи вошли в систему, как насчет кэша на пользователя или ESI?
ESIS
ESI - это отличная утилита, позволяющая хранить содержимое в кэше и при этом иметь динамические блоки на странице. Но для эффективного использования вам необходимо минимизировать количество обратных вызовов до минимума. Есть небольшой начальный модуль, который вы можете использовать в качестве основы для этого процесса - просто убедитесь, что вы затянули дыры в безопасности, по умолчанию он очень небезопасен - нет никаких ограничений на то, какие дескрипторы макета вы можете / не можете загрузить
Каждый раз, когда загружается загрузчик Magento, он снижает производительность примерно до 200 мс - даже до загрузки коллекции / рендеринга блока и т. Д. Так что, если у вас есть более чем 3 ESI, шансы на то, что вы закончили с более медленное время загрузки страницы с использованием Varnish + ESI для динамического содержимого, чем просто обход Varnish и передача запроса непосредственно в сам Magento.
Таким образом, чтобы эффективно использовать ESI, вы должны иметь возможность объединять несколько запросов в одном запросе.
Например, страница просмотра категории, в которой перечислены 20 товаров, должна показывать точные уровни запасов. Таким образом, вы используете ESI для каждого блока на странице. Это будет 20-кратное количество запросов акций ESI. В то время как запросы на акции очень легкие, одновременное выполнение их в 20 раз снизит производительность. Таким образом, вместо этого вы можете обслуживать весь блок / набор из 20 продуктов и просто получить этот 1x запрос. Но загрузка и рендеринг коллекции - это, пожалуй, самый медленный элемент на странице - так что вы мало что выиграли.
Для эффективного использования ESI необходимо правильное планирование и выполнение, иначе сайт будет работать медленнее, чем вообще не использовать Varnish.
Кэш-для каждого пользователя
Тогда есть альтернатива использования пользовательского кэша. Это плохая идея, если у вас нет сайта с очень низким трафиком. Ваш рейтинг попаданий будет ужасно низким - вероятность того, что посетитель попадет на ту же страницу, на которой он уже был, очень мала. И для каждого клиента эта страница размером 6 КБ будет занимать все больше и больше места в вашем хранилище Varnish.
Например, если вы выделили 1 ГБ для Varnish. Для типичного сайта, где пользователи просматривают 8 страниц за посещение, в среднем 6 из этих страниц будут уникальными. Это 28 посетителей на 1 МБ памяти. Тогда учитывайте ваши изображения, CSS и JS - они (к счастью) будут обычными, но все равно, вероятно, будут занимать хорошие 7-800 МБ доступного хранилища. Это оставляет вам 200 МБ свободного места, достаточного для кеширования 5600 уникальных посетителей.
Ну, мне все равно, я просто хочу лак
Хорошо, тогда вам нужно сделать следующее:
- Установите терминатор SSL, чтобы сидеть перед Varnish (например, stud / pound / nginx)
- Установите Лак на сервере
- Убедитесь, что вы
X-Forwarded-Forправильно настроили
- Установите модуль лака в вашем магазине
- Настройте VCL Varnish, чтобы исключить сторонние расширения
Поскольку первые 3 пункта выходят за рамки этого ответа, я оставлю это на ваше усмотрение. Пункт 4 - детская игра, а пункт 5 - продолжить чтение.
Самое важное в реализации Varnish - убедиться, что вы никогда не кэшируете контент, который никогда не должен кэшироваться.
Например.
- Обратные вызовы платежного шлюза
- Обзор корзины
- Клиент мой обзор аккаунта
- Оформить заказ (и соответствующие вызовы Ajax)
и т.п.
Для основных URL-адресов Magento существует довольно стандартный список URI, которые вы можете использовать в Varnish:
admin|checkout|customer|catalog/product_compare|wishlist|paypal
Но вам также нужно учитывать любые пользовательские / сторонние расширения, которые вы также используете, которые имеют собственные маршруты, маршрутизаторы и пространства имен. К сожалению, нет простого способа узнать, какие URL-адреса этих расширений можно и нельзя кэшировать. Таким образом, вы должны оценить каждый в отдельности.
Как правило, всякий раз, когда мы конфигурируем Varnish, мы начинаем с определения соответствующих маршрутов, маршрутизаторов и пространств имен, которые они могут занимать и откуда идти. Мы делаем это через SSH:
grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local
Это не даст вам точный список URL-адресов, но почти наверняка даст вам старт.
Мы не можем не подчеркнуть, насколько важно никогда не кэшировать контент, который не должен кэшироваться. Результаты могут быть катастрофическими.
В итоге
Как и любая другая оптимизация производительности сервера Magento, реализованная и настроенная правильно может действительно принести пользу. Но простое добавление программного обеспечения без надлежащей настройки не только сделает ваш магазин не быстрым, но и потенциально более медленным, небезопасным и менее надежным.