Полный кеш страницы на CE 1.8 - модуль Magento FPC? Лак? Оба?

magento.stackexchange https://magento.stackexchange.com/questions/13957

Вопрос

Так что я немного смущен, когда я изучаю полное кэширование страниц для сообщества издания 1.8. Я уже внедрил двухуровневый кэш Redis, CDN, настроенный MySQL's My.CNF для максимальной производительности (конечно, DB находится на отдельном сервере), и у меня есть 2 сервера, которые размещают наш магазин за балансировщиком нагрузки. Я говорю, что, чтобы отметить, что я не сразу же прыгаю за FPC, прежде чем внести первоначальные изменения в производительности.

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

До того, как только сейчас я думал о них как о двух отдельных объектах, которые вы могли бы реализовать его, помочь вашему сайту, но теперь я прочитал, похоже, подразумевает противоположное. Мой первоначальный план состоял в том, чтобы купить »Варень Advanced Pultear«Модуль для Magento (ранее« крошечный Brick Lightspeed FPC », я полагаю), поскольку он кажется самым популярным, хотя и прикосновением к более дорогой стороне (но, честно говоря, 350 долларов не очень для нашей компании, особенно для чего это может сделать). Я и 2 моих коллег -разработчика планировали учиться правильно и полностью внедрить его в нашу собственную, домашнюю тему, чтобы максимизировать то, что мы можем извлечь из этого. После этого в какой -то момент Дорога, я подумал, что также буду изучать внедрение лака - но, как я уже говорил ранее, я понял, что они отдельными.

Теперь, однако, я начинаю сталкиваться с расширениями, подобными этой Pagecache, питаемом на лаке, который является свободным, или этот вихревой кэш, питаемый кэшем для лака, который составляет почти 800 долларов США, которые являются модулями кэша Magento, которые работают непосредственно с лаком.

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

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

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

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

Спасибо!!!

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

Это было полезно?

Решение

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

  1. Называя вещи
  2. Кэш недействительный.

Дырочная удара попадает в категорию № 2 :)

Общий

Лучший подход состоит в том, чтобы начать в нижних точках стека и оптимизировать на переднем фронта Magento.

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

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

Mytop это удобный сценарий Perl на основе Linux, который имитирует команду Linux «Top» и даст вам представление о состоянии вашего экземпляра MySQL.

HTOP это Более надежный топ, строка Функция может помочь определить входы/ауты процесса для поиска потенциальных узких мест.

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

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

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

Apache или Nginx

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

Дело в точке:

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

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

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

PHP

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

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

Aoe_templatehints это здорово, чтобы определить, правильно ли ваши блоки кэшируют:

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

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

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

Могниффер инструмента от Magento ECG поможет легко определить плохой поведение кода на основе PDF, предоставленного выше. Однако это основан на Symfony/PHP-parser, но установлен через композитор.

Лак

one does not simply turn on varnish

Будучи сторонником того, что лак, являющимся автором, был девчонком ядра FreeBSD, он предлагает несколько сумасшедших временей второго нагрузки. Однако, если у вас даже есть некоторые из малейших различий в ваших шаблонах, которые не выходят из коробки, вы потратите время на настройку лака / Magento, чтобы HolePunch необходим контент. Большинство из них я видел, что просто будет Ajax'mify необходимые предметы, не имеющие лака.

Есть ряд модулей Magento, которые помогут облегчить эту дыру и кэшировать:

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

Magento CE FPC

Пока что лучшее, что я нашел, это: lesti :: fpc

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

Нет правильного ответа. В магазине должны быть динамические нагрузки на страницу Sub 3S и в идеале 1-2-х динамические нагрузки, подсекунду не требуется, в первую очередь является маркетинговой статистикой. Apache легко выучить и трудно выполнить, Nginx трудно выучить, и его легко выполнить, многие сайты переходят в Nginx, однако, чтобы иметь высококачественную архитектуру, основанную на Nginx, и Magento не прост.

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с magento.stackexchange
scroll top