Кэш полной страницы в CE 1.8 - модуль FPC Magento? Лак? И то и другое?

15

Так что я немного запутался, изучая Full Caching for Community Edition 1.8. Я уже внедрил двухуровневый Redis Cache, CDN, настроил MySQL my.cnf для максимальной производительности (конечно, если БД находится на отдельном сервере), и у меня есть 2 сервера, на которых размещается наш магазин за балансировщиком нагрузки. Я говорю это, чтобы указать, что я не сразу прыгаю на FPC, прежде чем делать начальные настройки производительности.

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

До сих пор я думал о них как о двух отдельных сущностях, которые вы могли бы реализовать, чтобы помочь вашему сайту, но теперь кое-что, что я прочитал, похоже, подразумевает обратное. Мой первоначальный план состоял в том, чтобы купить модуль « Warp Advanced Full Page Cache » для Magento (ранее «Tiny Brick Lightspeed FPC», я считаю), поскольку он кажется самым популярным, если коснуться более дорогой стороны (но, честно говоря, 350 долларов не много для нашей компании, особенно за то, что она может сделать). Я и двое из моих коллег-разработчиков планировали научиться реализовывать ее правильно и полностью в рамках нашей собственной, самодельной темы, чтобы максимизировать то, что мы можем из нее извлечь. После того, как это было сделано, в какой-то момент в будущем я подумал, что тоже буду заниматься реализацией Varnish - но, как я говорил ранее, я понял, что они разделены.

Однако теперь я начинаю сталкиваться с такими расширениями, как этот бесплатный PageCache Powered by Varnish или этот Vortex Cache Powered от Varnish Cache стоимостью почти 800 долларов США, которые представляют собой модули Magento Full Page Cache, которые работают непосредственно с Varnish.

Мой вопрос к вам, обмен стека, как я должен видеть FPC и Varnish? Как отдельные объекты? Если да, являются ли они взаимоисключающими? Это две стороны одной медали, которые я должен реализовать вместе? Или они похожи, но не исключают и не включают друг друга?

Могу ли я использовать Warp Advanced FPC, о которой я упоминал выше, с Varnish? Должен ли я использовать его с лаком? Или было бы лучше использовать другой FPC, если я планирую использовать Varnish? И еще, есть ли FPC настолько хороший, что мне не нужен Varnish? Или наоборот, я должен просто использовать Varnish и отказаться от идеи FPC?

Извините за стену текста, но я просматривал много статей, блогов и сообщений на форуме, и я не смог найти однозначного ответа на эти вопросы. Я действительно ценю вашу помощь и вклад в это дело =)

Ну и, наконец, быстрый вопрос о Varnish и веб-серверах. В настоящее время я использую обычную установку стека Apache LAMP, но некоторое время назад я видел, как люди в восторге от использования Nginx с Magento. Я сам провел несколько тестов, нагрузочных и нагрузочных тестов, и кажется, что он определенно может работать немного лучше в правильных условиях. Поэтому я подумывал о переходе в какой-то момент в ближайшем будущем. Повлияет ли это на мое желание и решение использовать FPC и / или Varnish?

Спасибо!!!

РЕДАКТИРОВАТЬ: О! И еще один быстрый вопрос - поскольку у меня есть два сервера, на которых размещается мой сайт за балансировщиком нагрузки (который также может быть увеличен по горизонтали в случае необходимости), я полностью использую Redis и Memcached, размещенные на отдельном сервере от Веб и БД для моих сессий и каждого уровня двухуровневого кэша Magento (ну, Zend). Я предполагаю, что FPC будет хранить свои данные в одной из этих систем? Нужно ли иметь конкретное расширение, чтобы хранить его там, или они все делают это? И хотя я полагаю, что это не повлияет на Varnish? Еще раз спасибо!!

ThatSourDiesel
источник
Очевидно, я могу поместить только две ссылки в мою стену текста из-за моей репутации. Какой способ побудить меня заняться троллингом за интернет-очки ... Тем не менее, вот ссылки: Vortex Cache на основе Varnish Cache и PageCache на основе Varnish
ThatSourDiesel
3
Я не могу дать много советов по поводу Varnish, но я рекомендую взглянуть на Lesti FPC - gordonlesti.com/lestifpc. Он абсолютно бесплатный, имеет дырокол , настраивается через администратора. Это абсолютно великолепно.
Пол
@ThatSourDiesel - можете ли вы рассказать нам, что вы сделали? Желательно по принятому ответу, если вы использовали его как минимум для своего решения.
СПРБР

Ответы:

28

Есть две сложные вещи в информатике:

  1. Называть вещи
  2. Аннулирование кэша.

Штамповка попадает в категорию # 2 :)

Общая

Наилучший подход - начать с нижних точек стека и оптимизировать до внешнего интерфейса Magento.


База данных и файловая система

Всегда должны быть первыми областями, на которых нужно сосредоточиться. Так как. I / O.

MyTop - это удобный Perl-скрипт на основе Linux, который будет имитировать команду top в Linux и даст вам представление о состоянии ваших экземпляров MySQL.

Htop - более надежная вершина. Функция strace может помочь определить входы и выходы процесса, чтобы найти потенциальные узкие места.

Iotop - еще один инструмент для мониторинга ввода / вывода.

Другие полезные служебные скрипты, такие как mysqltuner.pl и mysql tunning primer, могут дать представление о ваших переменных времени выполнения MySQL и дать совет, чтобы помочь. Имейте в виду, что они предназначены для руководства, так как лучший подход - это всегда оценка требований и настройка на основе известных собранных данных. Слепое действие может причинить больше ущерба, чем пользы. И преждевременный запуск этих без по крайней мере 24 часов переменных времени выполнения mysql может дать плохой совет.

Помните, что Percona , MariaDB и стандартный MySQL должны работать со всем вышеперечисленным. Предпочитая Percona в качестве форка MySQL, поскольку Magento очень загружен InnoDB, а XtraDB предлагает множество инструментов и улучшений для движка db.


Apache или Nginx

Все еще использую Apache, поскольку он хорошо послужил многим другим, включая меня. Я также использовал и настраивал Nginx. В то время как это действительно предлагает некоторые преимущества, есть кривая изучения. Несмотря на то, что оба варианта являются популярными, он предлагает некоторые преимущества по сравнению с Apache, один из них - меньший объем памяти. Однако тонкий Apache с PHP-FPM будет иметь такой же объем памяти.

Дело в точке:

Поскольку в этой статье речь шла о производительности, я должен отметить, что одним из самых простых способов помочь apache выбраться из своего пути является не использовать файлы .htaccess. Поместите то, что вы поместили бы в разделы каталога, установите для параметра AllowOverride значение «Нет», и в итоге вы не будете спрашивать apache об обходе всего пути к документу, чтобы выяснить, нужно ли ему обратить внимание на .htaccess или нет. Это простой, простой совет по настройке, который многие люди пропускают.

Чтобы облегчить эту проверку:

Очевидно, что использование CDN для облегчения любого из них поможет, но принесет дополнительные преимущества при оптимизации внешнего интерфейса, поскольку большинство браузеров конечных пользователей смогут подключаться к обоим серверам с одинаковым количеством ограничений на количество подключений. Это также освобождает Apache от необходимости прыгать через чеки и тому подобное, просто чтобы подать простое статичное изображение. Lighthttpd - это опция, если вы хотите запустить статический веб-сервер только для контента, кроме CDN.

PHP

PHP-FPM и APC. Используйте их, уберите все ненужные или ненужные модули PHP, которые не нужны для Magento.


Magento кодовая база

AOE_TemplateHints отлично подходит для определения правильности кэширования ваших блоков:

AOE_Profiler хорош для профилирования, обязательно включите профилирование на уровне БД (очевидно, в локальной среде / среде разработки). Это в сочетании с упомянутым ранее инструментом mytop облегчает поиск плохого поведения SQL.

Сторонние модули и пользовательский код

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

Инструмент Magniffer от Magento ECG поможет легко определить плохой код поведения на основе PDF, предоставленного выше. Однако он основан на symfony / php-parser, но устанавливается через composer.


лакировка

не просто включить лак

Поскольку сторонник Varnish, который был автором, был разработчиком ядра FreeBSD, он предлагает несколько сумасшедших времен загрузки за секунду. Однако, если у вас даже есть небольшие отличия в ваших шаблонах, которые не являются стандартными, вы потратите время на настройку лака / magento для точного пробивания необходимого контента. Большинство из того, что я видел, будет просто AJAX'ом определять необходимые элементы, не кэшированные из Varnish.

Существует несколько модулей Magento, которые помогут упростить пробивание дырок и кеширование:

В конечном итоге это должно произойти в конце вашего пути оптимизации, и МОЖЕТ потребовать некоторой настройки, чтобы все было правильно.


Magento CE FPC

На данный момент лучший CE FPC, который я нашел, это: Lesti :: FPC

это очень хорошо скомпонованный (все на основе наблюдателей) с открытым исходным кодом и бесплатный FPC для сообщества.


В конце дня используйте свое собственное тестирование и суждение.

Некоторое дальнейшее чтение:

B00MER
источник
2

Я немного опоздал к этой теме, я знаю, но если вы все еще ищете решение, вы можете рассмотреть, Evolved Caching . Это та же цена, что и у Warp, но это:

  • Очень быстрый и простой в установке и настройке - все отверстия и настройки выполняются изнутри администратора
  • Интегрируется непосредственно с Varnish и позволяет очищать и нагревать кэш Varnish из Magento.
  • Работает с интерфейсом form_key, представленным в 1.8 CE, как в Varnish, так и в собственном кеше.
  • Очень активно развивается с отзывчивой поддержкой. Регулярные новые версии с целью выпуска исправлений ошибок в течение нескольких дней после сообщения
  • Имеет обширную документацию, которая обновляется с каждым выпуском

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

Джонатан Хасси
источник
Ух ты, интересно. Я обязательно посмотрю на это. Я должен опубликовать обновление здесь. По сути, я решил использовать Varnish, а не модуль кеширования полной страницы, но я немного застрял в том, что делать с динамическими частями. ESI против AJAX, по большей части. Я опробовал лак с скипидаром, но когда у меня возникли проблемы с добавлением материала в корзину - я вытащил его. Оказывается, проблемы были связаны с моим обработчиком сохранения сессии memcached, который я обнаружил позже. Тем не менее, я все еще хочу восстановить Varnish, но мне нужно потратить некоторое время, чтобы убедиться, что все мои динамические части работают нормально.
ThatSourDiesel
1
Конечно хорошо Я не думаю, что Turpentine еще работает с 1.8 CE из-за включения form_key на веб-интерфейс - возможно, именно поэтому у вас возникли проблемы с добавлением в корзину. Лично я бы порекомендовал Ajax поверх ESI в основном потому, что ESI требует, чтобы вы отправили запрос в Magento до того, как страница будет доставлена, и это всегда будет медленным. Вам может быть интересно посмотреть на этот пост. fabrizio-branca.de/magento-varnish-ajax-vs-esi.html .
Джонатан Хасси
Я люблю блог Фабрицио! Определенно видел, что его модуль AJAX - это то, на что я ссылался, когда упоминал AJAX в своем последнем моем комментарии. У меня возникла проблема добавления в корзину из-за чего-то странного с memcached, которое мне удалось исправить. Тем не менее, несмотря на то, что они говорят, что скипидар не работает с 1.8, если вы не отключите form_key, мне показалось, что он работает нормально. Тем не менее, я не до конца понимал ESI, поэтому с тех пор он отключен, пока я не смогу потратить больше времени на внедрение и тестирование. Недавно я пропустил немного работы - сломал ключицу, пришлось сделать операцию.
ThatSourDiesel
Кстати, Evolved Caching - это ваш собственный модуль? Просто из любопытства - не могли бы вы позволить мне попробовать его на моем промежуточном сервере? Мы можем обсудить в PM доменные имена, а что нет, чтобы вы могли убедиться, что это на самом деле тестовый сервер, а не
рабочий
Я надеюсь, что вы поправляетесь после операции! Да, модуль разработан моей компанией, и мы очень рады, что вы можете испытать его на промежуточном / dev домене. Просто напишите нам по электронной почте, указав адрес электронной почты службы поддержки в левой колонке нашего магазина, и я заберу его - store.husseycoding.co.uk . Как примечание стороны, рад , что вы зафиксировали Memcached вопрос, стоит отметить , возможно, добавить в корзину могут появиться на работу под 1.8 для пользователя , который вызывает страницу в кэше , поскольку их форма ключа кэшируются, но очистить куки , чтобы получить новый сеанс + ключ формы, и вы, вероятно, найдете, что это не удается.
Джонатан Хасси
1

Мы написали FPC, который совместим с новым ключом формы Magento 1.8. Полный кэш страницы Брим: http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER отлично подходит для того, чтобы начать с низкого стека и идти вверх. FPC или Varnish должны быть примерно последними, что вы делаете. Мы проводим аудит производительности и часто находим проблемы с конфигурациями MySQL и APC, которые просто не работают. Как и размеры буфера Innodb, установленные по умолчанию, и база данных значительно превзошла их.

Мы не рекомендуем использовать любой FPC с Varnish, если он специально не предназначен для совместной работы. Как правило, мы не рекомендуем Varnish, если у вас нет нескольких мощных серверов, которые все настроены вместе с вашей кодовой базой и все еще пытаются справиться с трафиком. Обновление динамического контента может быть сложно с Varnish, особенно когда вы пытаетесь ограничить ваши запросы к бэкэнду Magento и, в свою очередь, уменьшить нагрузку. Если у вас есть одна или две веб-головы, выгода может не стоить времени и сложностей.

В большинстве случаев хороший FPC обеспечит вам необходимую производительность, конечно, после того, как ваш сервер и кодовая база будут настроены. С нашим FPC вы можете получить время генерации менее 15 мс в кэше уровня 1 и 100 мс в стандартном кэше. Наш кэш 1-го уровня используется для случаев, когда пользователь не вошел в систему и не имеет ничего в своей корзине, поскольку он не выполняет пробивание отверстий. Когда любое из этих условий ложно, используется стандартный кэш с поддержкой пробивки дырок.

Наш FPC имеет встроенную простую перфорацию и работает из коробки со всеми стандартными блоками Magento, а также любыми пользовательскими блоками, которые вы можете иметь. Это все настраивается через панель администратора.

Я бы рекомендовал придерживаться Redis, если у вас нет проблем с масштабированием. Он имеет поддержку тегов и намного быстрее, чем memcached с файлом или базой данных как медленный бэкэнд. Если вам нужны единообразные теги и очистка, вы должны использовать memcached с базой данных, когда у вас несколько веб-заголовков. Благодаря встроенной поддержке тегов Redis вам не нужно беспокоиться об этом. Вы также можете использовать Redis для своих сессий.

Я могу говорить за все FPC, но у нас вы можете настроить через администратора, где его хранить. Вы можете использовать стандартную серверную часть кэша Magento или указать пользовательские настройки для использования файлов, базы данных, APC, Redis, Memcache и оптимизированной файловой системы.

BrimSeth
источник
Может поручиться за доставку до 20 мс в браузер. Только Magento FPC я видел в реальном магазине.
Мелвин
0

Там нет правильного ответа. Магазин должен иметь динамическую загрузку страниц в 3 секунды и в идеале динамическую загрузку в 1–2 секунды, при этом дополнительная секунда не является необходимой и является в первую очередь маркетинговой статистикой. Apache легок в освоении и труден в исполнении, Nginx труден в освоении и прост в исполнении, многие сайты переходят на Nginx, однако иметь высококачественную архитектуру на основе Nginx и Magento непросто.

Многосерверные кластеры Magento уже сложны в реализации, и их еще сложнее поддерживать, если не использовать правильную архитектуру. Обычно мы работаем с более крупными кластерами, что делает работу более гладкой, включая ранжирование. Мы делаем это с помощью стандартной конфигурации установки с небольшими изменениями для среднесрочной и долгосрочной стабильности, ориентированной на динамическую загрузку страниц 1-2 с, что значительно упрощает обслуживание.

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

FPC - это последняя часть, если у вас динамическая загрузка менее 3 или выше, ваша архитектура может обрабатывать незначительные количества запросов посетителей, поскольку это влияет на ранжирование, поглощает всплески маркетинга и праздников, а также имеет бюджет, чтобы добавить сложность в архитектуру сервера - хостинг должен быть 0,5 -1% выручки для малых предприятий, большинство из которых в основном связаны с этим, вызывает много косвенных проблем в бизнесе.

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

VanquishTechnology
источник
-2

Вы можете использовать этот кеш страниц Magento, который будет соответствовать вашим потребностям и похож на лак. Он используется во многих крупнейших магазинах Magento. Некоторые особенности:

  1. Как и Varnish, он не использует соединение с базой данных для 90% запросов. В результате это очень быстро
  2. У него есть возможность автоматически сбрасывать страницы, когда такие вещи, как товарные запасы меняются, и это очень хорошо.
  3. Это многослойный кеш, поэтому он также поддерживает пробивание отверстий при входе пользователей (эти запросы требуют использования базы данных)

В качестве многоуровневого кэша он масштабируется даже для хранилищ с самым высоким трафиком и используется на многих сайтах с чрезвычайно высоким трафиком, которые получают пиковый трафик, например хранилища, размещаемые на SharkTank (телевизионное шоу)

Extendware
источник
Это не отвечает на вопрос автора о том, следует ли использовать лак или FPC.
Стив Роббинс
@extendware вы должны раскрывать, когда вы являетесь автором продукта. Мы приветствуем ценный вклад, но не приветствуем откровенный спам.
Филвинкл