Получение лака для работы с Magento

Ответ 1

http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ описывает расширение Magento, которое обеспечивает полный кеш страниц с помощью лака. Это расширение зависит от конфигурации Varnish, опубликованной в github.

Это уже реализованные функции:

• Конфигурация рабочего лака
• Включить полное кэширование страниц с использованием Varnish, супер быстрого кэширования HTTP-обратного прокси.
• Серверы лаков настраиваются в Admin, в разделе System/Configuration/General - Varnish Options
• Автоматически очищает (только) кешированные страницы, когда сохраняются продукты, категории и страницы CMS.
• Добавляет новый тип кэша в Magento Admin под управлением System/Cache и предлагает дезактивировать кеш и обновить кеш.
• Сообщает пользователям Admin о сохранении навигации в категории и обновлении кэша лакокрасочного покрытия, чтобы меню обновлялось для всех страниц.
• Автоматически отключает кеш-лак для пользователей, у которых есть товары в корзине или вошел в систему, и т.д.)
• Конфигурация по умолчанию для лака, предлагаемая для обеспечения работоспособности модуля. Экранные снимки: https://github.com/madalinoprea/magneto-varnish/wiki

Ответ 2

Как кэшировать Magento в лаке (теория) - для этого

1) Статические активы (например, изображения, CSS, JS). Это простой общий шаблон, который включает в себя обнаружение запросов, относящихся к этой категории, и установку времени кеша (или полагаться на время кэша, отправляемое сервером происхождения ) Пример этого в форме gist

2) HTML-документы. Это гораздо более сложная часть хорошего решения Magento. Это важно для кэширования HTML-документов в Varnish, чтобы улучшить производительность Magento. Создание HTML-документа является самой дорогостоящей (отнимающей много времени) вещью, которую сделает сервер Magento.

Проблема с кэшированием HTML-документов происходит из персонализированного контента.

Персонализированный контент и HTML-документы

Magento и все другие сайты электронной торговли управляют состоянием конкретного пользователя, хотя сеанс. Сеанс - это запись этого конкретного статуса пользователей на вашем сайте. Это охватывает такие вещи, как: "Привет, Боб" - в верхней части страницы "4 вещи в вашей корзине" - статус вашей корзины покупок на каждой странице

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

Как кэшировать страницы HTML, если страницы HTML содержат персонализированную информацию о том, кто такой человек и что находится в корзине?

Существует два основных способа достижения этого: Загрузка персонализированных элементов страницы с помощью дополнительных запросов после загрузки страницы Общим методом реализации является использование AJAX для запроса элементов страницы, которые персонализированы Использование технологии для маркировки компонентов документа HTML как кэшируемые, а другие - недоступны (или не доступны для пользователей). Larn поддерживает технологию 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 и будет работать из коробки, чтобы улучшить скорость вашего сайта.

Как сделать лак и Magento хорошо работать

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

Недавно мы построили эту инфраструктуру для запуска Varnish в качестве службы в облаке (с полными логами/метриками) - www.section.io - Plug в стороне это может быть самым важным элементом для фактического успеха с вами проекта Varnish and Magento, поскольку вам нужно постоянно настраивать свою реализацию, чтобы управлять такими вещами, как переменные строки запросов в URL-адресах (Hello google analytics "gclid"!), что может уменьшить ваш кеш-хит ставки резко

Ответ 3

Если вы используете 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);
# }

Ответ 4

Я предполагаю, что cookie сеанса, который Magento посылает всем пользователям - у меня была аналогичная проблема с Varnish + Redmine.

Причина, по которой Varnish не кэширует ваши страницы, заключается в том, что по умолчанию она кэширует только то, что, безусловно, безопасно, и пользователи с куки файлами обычно видят разные вещи для заданной загрузки страницы, например, если они вошли в систему, то, возможно, их имя пользователя находится в верхней части каждой страницы, поэтому страница не может быть кэширована †.

Однако многие фреймворки предоставляют сеансовые куки для пользователей, которые также не вошли в систему. Боюсь, я вообще не знаю Magento, поэтому я не могу предсказать последствия игнорирования этого cookie - на Redmine, игнорируя cookie, означает, что пользователи не могут войти в систему, и все формы перестали работать (потому что у них больше не было CSRF маркер).

Скорее всего, лучше справиться с этим со стороны Magento, если вы сможете - Varnish будет слушать верхние заголовки, чтобы определить, что можно кэшировать и т.д.

Если вы не можете, вы можете смягчить его из конфигурации Varnish. Вы захотите убедиться, что заголовок Set-Cookie не отправлен из кеша, и вы также захотите сбросить файл cookie клиента на запросы для страниц, на которых этот файл cookie не влияет. Это означает, что вам понадобятся исключения для таких вещей, как экран входа в систему или любая страница, требующая входа в систему (если только Magento не установит отдельный файл cookie после входа в систему, что упростит ситуацию).

В документации по Varnish (которую я могу рекомендовать как ресурс) есть несколько страниц по увеличению скорости, в том числе специально для удаления файлов cookie на некоторых страницах, а не другие.

† Возникает исключение, если вы используете краевая сторона включает.

Ответ 5

Мы разработали модуль под названием PageCache, основанный на Varnish, который позволяет Magento и Varnish плавно взаимодействовать, предоставляя хорошо протестированный файл конфигурации Varnish (VCL) и плотно интегрированный модуль Magento с множеством опций для управления установкой Varnish от Magento бэкенд. Проверьте это на Magento Connect:

http://www.magentocommerce.com/magento-connect/Phoenix/extension/6322/varnish_cache

Ответ 6

Это, я думаю, объясняет, как мы могли отказаться от использования лака с magento

Если вы используете модуль aoe_static и мой пользовательский vcl для лака 3, он очищает файлы cookie от ответа на кешированную страницу. Он должен сделать это в vcl fetch. Затем файлы cookie можно установить из меньшего ответа ajax, который загружает динамический контент. Это поддерживает ваши сеансы, корзину и т.д. Этот ответ ajax может быть "pipe" ed в vcl recovery.

У меня не было никаких проблем с этим, но я не пробовал его на производственном сайте.

Динамические блоки должны быть заменены заполнителями через макет xml. Если вам нравятся эти замены, может быть лаковая сторона с красной частью или пользовательская реализация ajax.

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

Если вы используете модуль aoe_static, вы заметите, что вызывается loadLayout, но помните, какие дескрипторы переданы этому loadLayout. это не то же самое, что и запрос макета для вашей страницы, но он получает дескриптор по умолчанию для вас.

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

Возможно, вы можете использовать observer - cataloginventory_stock_item_save_after - для проверки уровней запасов (я не проверял это). Затем кеш может быть очищен на основе URL-адресов продуктов. Очень легко получить URL-адреса категории, в которых продукт появится и очистит их в одно и то же время.

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

Но как бороться с многоуровневыми навигационными URL-адресами сложнее. вам нужно будет сохранить параметры строки запроса, которые приложение выполнило с использованием URL-адреса списка базовых категорий в качестве ключа, а затем прочитать и очистить эти URL-адреса в наблюдателе. Это сохранение параметров строки запроса было бы достаточно простым, используя ответ перед отправкой, проверяя объект запроса с помощью регулярного выражения и регистрируя строки запроса, разделенные запятыми.

Я ошибаюсь, думая, что ни один из текущих модулей не имеет отношения к уровням запасов для многоуровневой навигации?

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

Зарезервируйте этот вопрос для получения более подробной информации о проблемах, с которыми вы столкнетесь с этим вопросом - полнофункциональный кеш полнотекстового источника magento

Ответ 7

http://moprea.ro/2011/feb/16/magento-performance-optimization-varnish-cache-2/

Не уверен, что это помогает, но я это понял.

Я действительно пытался получить лак для работы раньше, и я потерпел неудачу. Я предлагаю вам получить APC + Memcached + tmpfs сеансы/кеш, прежде чем попробовать лак.