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

Так что я немного запутался, изучая 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? Еще раз спасибо!!

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

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

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

Общая

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

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

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

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

• https://github.com/jzawodn/mytop

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

• https://github.com/hishamhm/htop

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

• http://guichaz.free.fr/iotop/

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

• http://mysqltuner.pl
• https://launchpad.net/mysql-tuning-primer

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

• http://www.percona.com/software
• https://mariadb.org/en/about/

Apache или Nginx

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

• http://arstechnica.com/business/2011/11/a-faster-web-server-ripping-out-apache-for-nginx

Дело в точке:

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

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

• https://github.com/preinheimer/htaccessConverter

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

PHP

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

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

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

• https://github.com/fbrnc/Aoe_TemplateHints
• http://www.fabrizio-branca.de/magento-advanced-template-hints-20.html

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

• https://github.com/fbrnc/Aoe_Profiler

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

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

• http://info.magento.com/rs/magentocommerce/images/Conquer_the_5_Most_Common_Magento_Coding_Issues_to_Optimize_Your_Site_for_Performance.pdf

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

• https://github.com/magento-ecg/magniffer

лакировка

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

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

• AOE_Static: https://github.com/AOEmedia/Aoe_Static
• Скипидар Nexcess: https://github.com/nexcess/magento-turpentine

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

Magento CE FPC

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

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

• http://gordonlesti.com/lestifpc/
• https://github.com/GordonLesti/Lesti_Fpc (github в случае неработающей будущей ссылки)

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

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

• http://www.kingletas.com/2012/08/caching-performance-optimization.html
• https://www.sonassi.com/knowledge-base/magento-with-varnish/
• http://info.magento.com/rs/magentocommerce/images/HostandBoastBestPracticesForMagentoHosting.pdf

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

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

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

Мы написали 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 и оптимизированной файловой системы.

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

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

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

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

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

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

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

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