Сначала, пожалуйста, простите меня за полное отсутствие понимания лака. Это мой первый шаг – сделать что-нибудь с лаком.
Я следую примеру: http://www.kalenyuk.com.ua/magento-performance-optimization-with-varnish-cache-47.html
Однако, когда я устанавливаю и запускаю это, Varnish, похоже, не кэширует. Я получаю заголовок X-Varnish с одним номером и заголовком Via, который имеет значение 1.1 лак
Мне сказали (моим провайдером), что из-за следующего файла cookie, который Magento устанавливает:
Set-Cookie: frontend=6t2d2q73rv9s1kddu8ehh8hvl6; expires=Thu, 17-Feb-2011 14:29:19 GMT; path=/; domain=XX.X.XX.XX; httponly
Они сказали, что я либо должен изменить Magento, чтобы справиться с этим, либо настроить Varnish, чтобы справиться с этим. Поскольку изменение Magento не может быть и речи, мне было интересно, может ли кто-нибудь дать мне понять, как настроить Larn для обработки этого файла?
http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ описывает расширение Magento, которое обеспечивает полный кеш страниц с помощью лака. Это расширение зависит от конфигурации Varnish, опубликованной в github.
Это уже реализованные функции:
1) Статические активы (например, изображения, CSS, JS). Это простой общий шаблон, который включает в себя обнаружение запросов, относящихся к этой категории, и установку времени кеша (или полагаться на время кеша, отправляемое сервером происхождения). Пример это в форме
2) HTML-документы. Это гораздо более сложная часть хорошего решения Magento. Это важно для кэширования HTML-документов в Varnish, чтобы улучшить производительность Magento. Генерация HTML-документов является самой дорогостоящей (отнимающей много времени) вещью, которую сделает сервер Magento.
Проблема с кэшированием HTML-документов происходит из персонализированного контента.
Magento и все другие сайты электронной торговли, управляют состоянием конкретного пользователя, хотя сеанс. Сессия – это запись статуса конкретного пользователя на вашем сайте. Это охватывает такие вещи, как «Hello Bob» – вверху страницы «4 вещи в вашей корзине» – статус вашей корзины покупок на каждой странице
Это элементы, которые не могут быть разделены между пользователями и могут вызвать серьезную проблему, если это произойдет (мы называем это «утечкой сеанса»).
Как кэшировать HTML-страницы, если страницы HTML содержат персонализированную информацию о том, кто такой человек и что находится в корзине покупок?
Существует два основных способа достижения этого: загрузка персонализированных элементов страницы с помощью дополнительных запросов после загрузки страницы. Обычный метод реализации заключается в использовании AJAX для запроса элементов страницы, которые персонализированы. Использование технологии для маркировки компонентов документа HTML как кэшируемые и другие недоступны (или не доступны для пользователей). Лак поддерживает технологию ESI (Edge Side Includes), которая позволяет кэшировать различные части HTML-документа по-разному.
Стратегия реализации вашего лака должна учитывать персонализацию пользователя.
Magento 1.X. Наиболее широко используемый метод кэширования HTML-документов в Magento версии 1 – это продукт с открытым исходным кодом Magento Turpentine (от Nexus). Это плагин, который установлен (через Magento Connect) и автоматически добавляет теги ESI в ваши HTML-документы, чтобы Larnish мог кэшировать эти ресурсы. Установка / руководство Magento Turpentine
Magento 2.X – Последняя версия Magento (в настоящее время в бета-версии) поддерживает Varnish как рекомендуемое решение для кэширования HTML на производстве. Это отличная новость, Лак – рекомендуемый вариант от Magento и будет работать из коробки, чтобы улучшить скорость вашего сайта.
Развертывание – это одно дело. Следующие шаги, когда у вас есть решение Varnish Magento, выполненное и работающее, – это понять, насколько хорошо его выполнение. Получение показателей по частоте попадания в кеш и подробные журналы на основе запроса по запросам может быть проблемой, поскольку это предполагает развертывание целого ряда дополнительных инфраструктур (или застревание, выполняющее ручной сбор журналов на разовой основе).
Недавно мы построили эту инфраструктуру для запуска Varnish в качестве сервиса в облаке (с полными журналами / метриками) – http://www.section.io – Отвлечь это, это может быть самым важным элементом для фактического успеха с вашим проектом Varnish and Magento, как вам нужно постоянно настраивать вашу реализацию для управления такими вещами, как переменные строки запросов в URL-адресах (Hello google analytics «gclid»!), которые могут значительно снизить частоту попадания в кеш
Если вы используете Varnish 3.0, вам, возможно, придется изменить конфигурацию .vcl. Вот что я использую с пурпуром и лаком 3:
# This is a basic VCL configuration file for varnish. See the vcl(7) # man page for details on VCL syntax and semantics. # # Default backend definition. Set this to point to your content # server. # backend default { .host = "127.0.0.1"; .port = "8080"; } acl trusted { "127.0.0.1"; "127.0.1.1"; # Add other ips that are allowed to purge cache } # # http://www.varnish-cache.org/docs/2.1/tutorial/vcl.html#vcl-recv # @param req Request object sub vcl_recv { if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; } else { set req.http.X-Forwarded-For = client.ip; } if (req.request == "PURGE") { # Allow requests from trusted IPs to purge the cache if (!client.ip ~ trusted) { error 405 "Not allowed."; } ban("req.url ~ " + req.url); error 200 "Ok"; #We don't go to backend #return(lookup); # @see vcl_hit } if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { /* Non-RFC2616 or CONNECT which is weird. */ return (pipe); } # Cache only GET or HEAD requests if (req.request != "GET" && req.request != "HEAD") { /* We only deal with GET and HEAD by default */ return (pass); } # parse accept encoding rulesets to normalize if (req.http.Accept-Encoding) { if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm remove req.http.Accept-Encoding; } } # Rules for static files if (req.url ~ "\.(jpeg|jpg|png|gif|ico|swf|js|css|gz|rar|txt|bzip|pdf)(\?.*|)$") { set req.http.staticmarker = "1"; unset req.http.Cookie; return (lookup); } # Don't cache pages for Magento Admin # FIXME: change this rule if you use custom url in admin if (req.url ~ "^/(index.php/)?admin") { return(pass); } # Don't cache checkout/customer pages, product compare # if (req.url ~ "^/(index.php/)?(checkout|customer|catalog/product_compare|wishlist)") { # return(pass); # } # Don't cache checkout/customer pages, product compare if (req.url ~ "/(checkout|customer|catalog/product_compare|wishlist)/") { return(pass); } # Don't cache till session end if (req.http.cookie ~ "nocache_stable") { return(pass); } # Unique identifier witch tell Varnish use cache or not if (req.http.cookie ~ "nocache") { return(pass); } # Remove cookie unset req.http.Cookie; set req.http.magicmarker = "1"; #Instruct varnish to remove cache headers received from backend return(lookup); } sub vcl_pipe { # # Note that only the first request to the backend will have # # X-Forwarded-For set. If you use X-Forwarded-For and want to # # have it set for all requests, make sure to have: # # set req.http.connection = "close"; # # here. It is not set by default as it might break some broken web # # applications, like IIS with NTLM authentication. return (pipe); } #sub vcl_pass { # return (pass); #} #sub vcl_hash { # set req.hash += req.url; # if (req.http.host) { # set req.hash += req.http.host; # } else { # set req.hash += server.ip; # } # return (hash); # } # Called after a cache lookup if the req. document was found in the cache. sub vcl_hit { if (req.request == "PURGE") { ban_url(req.url); error 200 "Purged"; } # # ATTENTION!! I had to comment this to make it work on vernish 3.0!!!! # error message: # Symbol not found: 'obj.cacheable' (expected type BOOL): # # I'm not sure about it, please check!!! # #if (!obj.cacheable) { # return (pass); #} return (deliver); } # Called after a cache lookup and odc was not found in cache. sub vcl_miss { if (req.request == "PURGE"){ error 200 "Not in cache"; } return (fetch); } # Called after document was retreived from backend # @var req Request object. # @var beresp Backend response (contains HTTP headers from backend) sub vcl_fetch { set req.grace = 30s; # Current response should not be cached if(beresp.http.Set-Cookie ~ "nocache=1") { return (deliver); } # Flag set when we want to delete cache headers received from backend if (req.http.magicmarker){ unset beresp.http.magicmarker; unset beresp.http.Cache-Control; unset beresp.http.Expires; unset beresp.http.Pragma; unset beresp.http.Cache; unset beresp.http.Server; unset beresp.http.Set-Cookie; unset beresp.http.Age; # default ttl for pages set beresp.ttl = 1d; } if (req.http.staticmarker) { set beresp.ttl = 30d; # static file cache expires in 30 days unset beresp.http.staticmarker; unset beresp.http.ETag; # Removes Etag in case we have multiple frontends } return (deliver); } # Called after a cached document is delivered to the client. sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT ("+obj.hits+")"; } else { set resp.http.X-Cache = "MISS"; # set resp.http.X-Cache-Hash = obj.http.hash; } return (deliver); } # # sub vcl_error { # set obj.http.Content-Type = "text/html; charset=utf-8"; # synthetic {" # <?xml version="1.0" encoding="utf-8"?> # <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" # "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> # <html> # <head> # <title>"} obj.status " " obj.response {"</title> # </head> # <body> # <h1>Error "} obj.status " " obj.response {"</h1> # <p>"} obj.response {"</p> # <h3>Guru Meditation:</h3> # <p>XID: "} req.xid {"</p> # <hr> # <address> # <a href="http://www.varnish-cache.org/">Varnish cache server</a> # </address> # </body> # </html> # "}; # return (deliver); # }
Я предполагаю, что это cookie сеанса, который Magento посылает всем пользователям – у меня была аналогичная проблема с Varnish + Redmine.
Причина, по которой Varnish не кэширует ваши страницы, заключается в том, что по умолчанию она кэширует только то, что, безусловно, безопасно, и пользователи с куки-файлами обычно видят разные вещи для заданной загрузки страницы, например, если они вошли в систему, возможно, их имя пользователя находится в в верхней части каждой страницы, поэтому страница не может быть кэширована †.
Однако многие фреймворки предоставляют сеансовые куки для пользователей, которые также не вошли в систему. Боюсь, я вообще не знаю Magento, поэтому я не могу предсказать последствия игнорирования этого cookie – на Redmine, игнорируя cookie, означает, что пользователи не могут войти в систему, и все формы перестали работать (потому что у них больше не было CSRF маркер).
Вероятно, было бы лучше справиться с этим со стороны Magento, если вы можете – лак будет слушать заголовки восходящего потока, чтобы определить, что можно кэшировать и т. Д.
Если вы не можете, вы можете смягчить его из конфигурации Varnish. Вы хотите убедиться, что заголовок Set-Cookie не отправлен из кеша, и вы также захотите удалить cookie клиента на запросы для страниц, на которых этот файл cookie не влияет . Это означает, что вам понадобятся исключения для таких вещей, как экран входа в систему или любая страница, требующая входа в систему (если только Magento не установит отдельный файл cookie после входа в систему, что значительно упростит работу).
В документации по лакированию (которую я могу настоятельно рекомендовать как ресурс) есть несколько страниц по увеличению числа попаданий, в том числе для удаления файлов cookie на некоторых страницах, а не других .
† Существует исключение, которое есть, если вы используете граничную сторону .
Мы разработали модуль под названием PageCache, основанный на Varnish, который позволяет Magento и Varnish играть плавно вместе, предоставляя хорошо протестированный файл конфигурации Varnish (VCL) и плотно интегрированный модуль Magento с множеством опций для управления установкой Varnish из бэкэнда Magento. Проверьте это на Magento Connect:
http://www.magentocommerce.com/magento-connect/Phoenix/extension/6322/varnish_cache
Это, я думаю, объясняет, как мы можем отказаться от использования лака с magento
Если вы используете модуль aoe_static и мой пользовательский vcl для лака 3, он очищает файлы cookie от ответа на кешированную страницу. Он должен сделать это в vcl fetch. Затем файлы cookie можно установить из меньшего ответа ajax, который загружает динамический контент. Это поддерживает ваши сеансы, корзину и т. Д. Этот ответ ajax может быть «pipe» ed в vcl recovery.
Я не испытывал никаких проблем с этим, но не пробовал это на производственном сайте.
Динамические блоки должны быть заменены заполнителями через макет xml. Если вам нравятся эти замены, может быть лаковая сторона с красной частью или пользовательская реализация ajax.
При загрузке динамического содержимого из aoe_static (или любых других типов ajax-методов, которые вы предпочитаете), хорошо помнить, что вы все еще можете использовать макетную систему magentos, например создать дескриптор для вашего вызова ajax с вложенными блоками, которые будут отображаться.
Если вы используете модуль aoe_static, вы заметите, что вызывается loadLayout, но помните, какие дескрипторы передаются этому loadLayout. это не то же самое, что и запрос макета для вашей страницы, но он получает дескриптор по умолчанию для вас.
Другая проблема – уровни запасов. Когда у продукта больше нет достаточного запаса для добавления в корзину, он все равно будет отображаться в списках продуктов и в качестве вариантов для конфигурируемых и сгруппированных продуктов.
Возможно, вы можете использовать observer – cataloginventory_stock_item_save_after – для проверки уровней запасов (я этого не проверял). Затем кеш может быть очищен на основе URL-адресов продуктов. Достаточно легко получить URL-адреса категории, в которые будет отображаться продукт, и очистить их одновременно.
В модуле phoenix есть способы делать подобные чистки, если вы хотите, чтобы простая реализация выполнялась только через наблюдателей.
Но как бороться с многоуровневыми навигационными URL-адресами сложнее. вам нужно будет сохранить параметры строки запроса, которые приложение выполнило с использованием URL-адреса списка базовых категорий в качестве ключа, а затем прочитать и очистить эти URL-адреса в наблюдателе. Это сохранение параметров строки запроса было бы достаточно простым, используя ответ перед отправкой, проверяя объект запроса с помощью регулярного выражения и регистрируя строки запроса, разделенные запятыми.
Я ошибаюсь, думая, что ни один из текущих модулей не имеет дело с уровнями запасов для многоуровневой навигации?
Я думаю, что хороший готовый модуль для лака необходим в сообществе с открытым исходным кодом, поскольку все остальные отсутствуют. лично я планирую использовать только платные полнотекстовые кеши с серверами с балансировкой нагрузки и, возможно, лак, чтобы ловить изображения и запросы css. Если кто-то не захочет объединить усилия, чтобы сделать правильный лак, или я был бы рад помочь с проблемами для ваших сайтов, если бы эта работа могла быть добавлена к реализации с открытым исходным кодом, которая лучше справляется со всеми этими проблемами.
проверьте этот вопрос для получения более подробной информации о проблемах, с которыми вы столкнетесь с этим вопросом – полнофункциональный кеш полнотекстового ввода magento
http://moprea.ro/2011/feb/16/magento-performance-optimization-varnish-cache-2/
Не уверен, что это помогает, но я это понял.
Я на самом деле пытался получить лак для работы раньше, и я потерпел неудачу. Я бы предложил вам получить APC + Memcached + tmpfs сеансы / кеш, прежде чем попробовать лак.