Предварительный прогрев полностраничного кэша Magento Enterprise

19

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

Magento включает в себя встроенный cronjob для сканирования сайта и прогревания FPC рано утром.

Я видел и слышал о проблемах, вызванных тем, что ранние утренние задания выполнялись слишком долго, что мешало запуску других заданий, и хотел бы знать, что другие используют или предложат использовать для этого. У меня есть пара идей:

  • Соберите сценарий оболочки для сканирования каждой страницы в созданном файле карты сайта.
  • Используйте отдельную запись crontab и короткий PHP-скрипт для начальной загрузки Magento и непосредственного запуска процесса сканирования.

Любые мысли и / или опыт по этому поводу можно только приветствовать!

performance cache magento-enterprise full-page-cache cron davidalger
источник
1
На самом деле вы можете вызвать сканер Enterprise из отдельного файла и использовать crontab вашего сервера для его запуска, чтобы он не мешал.
Мульт Ван Дурен

Ответы:

16

Вы можете использовать осаду в сочетании с sitemap.xmlфайлом, как это делает MageSpeedTest .

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

Тогда беги

siege -i -c 1 -t 7200s -f urls.txt

Контент получен отсюда .

Эшли Шредер
источник
Вы также можете добавить задержку между запросами, используя–delay
Бен Лессани - Сонасси
Примечание. Эти команды sed не работают в Darwin, но работают в CentOS.
Давидгер
1
Это не гарантирует, что каждый URL будет «подогрет». siege будет случайным образом выбирать URL для попадания из файла, но не обязательно будет посещать каждый URL.
Джо Констант
22

Мы просто не - вообще. Когда-либо. Мы будем говорить это снова и снова, но

Кэширование! = Производительность

Ваш сайт должен быть быстрым без добавления FPC (или Varnish для этого факта). Всегда будет время, когда контент не заполнен (ваш сценарий выше).

В незагруженном магазине время загрузки страницы с FPC не должно быть намного более впечатляющим, чем без FPC; Magento вполне может рассчитывать на < 400msзагрузку страниц на стандартных кешах (на страницах категории / продукта / поиска). FPC понизит это до < 80ms- но идет с оговорками.

  1. Информация об акциях / ценах устарела до аннулирования или истечения срока действия TTL

  2. Новые товары / более релевантный поиск устарел до аннулирования или истечения срока действия TTL

    и т.п.

Почему опора на FPC (или лак) - плохая идея

Если вы хотите постоянно проверять, заполнены ли кэши вручную, вероятно, есть несколько причин

  1. У вас недостаточно естественного шага, чтобы держать кешированные загрунтованными (см. «Где полезен FPC»)
  2. Ваш сайт слишком медленный без них

Вы не можете кэшировать все

Если вы берете магазин только с 5 категориями, вложенными 2 уровня глубиной, 5 фильтруемых атрибутов, 5 вариантов атрибутов каждый и 1000 товаров; то есть много возможных комбинаций.

25 вариантов на выбор, выбирая один до 5 раз подряд - я не статистик , но я знаю, что это ... (при условии, что количество параметров атрибута не уменьшается полностью)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

Хорошо, вышеприведенный сценарий маловероятен, как я мог бы предположить, в 3 клика - количество доступных продуктов уменьшилось бы настолько, чтобы клиент мог найти свой продукт. Так что даже если бы это было ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations

Тогда раз, что на 5 категорий, то есть 625 URL. На этом этапе мы говорим о крошечном каталоге и полностью игнорируем все URL-адреса продуктов.

Мы также не учитываем, что если у вас есть вложенные категории с is_anchorвключенным, это будет увеличиваться в геометрической прогрессии.

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

Если у ваших страниц было время загрузки страницы 0,4 с, а у вас 8-ядерный процессор - тогда ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 минуты, неплохо - но давайте представим, что у вас было время загрузки страницы 2 с

625 * 2 = 1250 / 8 = 156 seconds

Но если вы взяли максимально возможный сценарий

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

Так что это ваш рабочий сервер, при 100% загрузке процессора в течение 15 минут. Вы бы снизили скорость сканирования пропорционально желаемому TTL.

Таким образом, если вы хотите, чтобы содержимое имело TTL 3600 с, сканирование может быть в 4 раза медленнее - т.е. только 25% ЦП выделено для сканирования. Это большой ресурс только для того, чтобы поддерживать содержание категории в заглавии - на данном этапе мы даже не учитывали продукты, условия поиска или дополнительные просмотры магазина.

Фактически, просто взглянув на явный размер комбинаций в catalog_url_rewritesтаблице (который даже не учитывает параметры от многоуровневой навигации), можно получить представление о том, сколько URL-адресов вам может понадобиться сканировать.

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

Где FPC полезен

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

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

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

Кому интересно, я все равно хочу ползти

Ну, тогда у вас есть два варианта

  1. Сканирование по шаблону (например, карта сайта)
  2. Извлекайте ссылки постранично и сканируйте каждый

И есть много утилит, чтобы сделать оба из них, вот некоторые, о которых я знаю

  1. маг-perftest
  2. HTTrack
  3. Nutch
  4. Sphider
  5. Crawler4j

Использование Mage-Perftest

Вы можете довольно легко сканировать свой магазин с помощью Mage-Perftest, сначала загрузив его

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

Затем определите процесс сканирования, используя карту сайта Magento (вы можете настроить ее, создав карту сайта с любыми URL-адресами, при условии, что URL-адреса заключены в <loc></loc>теги). Следующая команда прочитает все URL-адреса из файла карты сайта, а затем сканирует (только PHP) URL-адреса в течение 1440 минут (1 день). Если сервер превышает 20% процессорного времени или средняя загрузка составляет 2 - сканирование будет временно приостановлено.

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2

Если у вас 1000 URL-адресов, просканированных за 1 день, это будет ок. 1 запрос каждые 86 секунд ~ цель 0,011 RPS

Бен Лессани - Сонасси
источник
Вы открываете линию, это очень верно… Кэширование страниц - не способ достижения производительности. Я знаю это. Вы не знаете, сколько раз я говорил клиентам одно и то же. Честно говоря, я никогда не настраивал сайт, на котором у нас был бы сканер, заполняющий FPC, и видел, как он использовался только один раз, когда клиент включил его в админке ... замедляя процесс, так как он использует теги файлового кэша. Основная причина, по которой я спрашиваю, заключается в том, что я изучаю идеи, связанные с этим, основываясь на некоторых исследованиях в белой книге Nexcess. Для сайтов с безумно высоким трафиком заполнение кеша после его
очистки
1
Я уважаю Nexcess - но их белая бумага фокусируется очень сильно на кэширование для достижения производительности - вместо обеспечения среды уже производительное и что код является чистым, быстрым и эффективным. Мы предоставляем лак для наших клиентов - но не защищаем его использование, пока не потребуется. Только тогда как средство для снижения затрат на инфраструктуру - т.е. когда ~ 94% неконвертирующего / проверочного трафика потребляет циклы ЦП. Кэширование обеспечивает хорошую искусственную статистику тестов - но на самом деле ничего не значит, если TTL слишком длинные (устаревший контент) - или не хватает трафика для его заполнения.
Бен Лессани - Сонасси
1
Для сайтов с безумно высоким трафиком - у нас их несколько, и пытаться поддерживать горячий кеш при помощи искусственного сканирования бессмысленно - естественный трафик делает это просто замечательно. Во всяком случае, сканирование просто удаляет ресурсы, которые в противном случае использовались бы клиентами.
Бен Лессани - Сонасси
Я позволю себе не согласиться с тем, что они используют кеширование для повышения производительности. Они показывали, какую пропускную способность может достичь кластер 2 + 1. Они даже не касались времени загрузки страницы, только пропускная способность транзакций. Аппаратное обеспечение, которое у них есть, оптимизировано настолько, насколько вы можете… и да, я понимаю влияние TTL на кэшированный контент. Просто повторюсь, я не стремлюсь к достижению производительности здесь, у нас уже есть это. Что это будет исследовать, так это способы обойти лаги / падения пропускной способности из-за раннего утреннего сброса кэша, то есть до того, как нормальный трафик подхватывает.
Давидгер
1
Я запутался тогда. Если ваш магазин уже быстр - но падает, когда вы очищаете кеш. Либо: а) Не очищайте кэш утром, сделайте это накануне вечером, и пусть поисковые роботы (google / bing и т. Д.) Выполнят за вас работу, или б) получите подходящую инфраструктуру. Если ваш магазин зависит от FPC / Varnish для предотвращения задержки / замедления - тогда звучит так, будто вы бежите на
острие
0

Я сохраню свою полную напыщенную речь для поста в блоге в эти дни, но пока у меня есть пик на моем маленьком нагревателе кеша wfpc.

Тестирование производительности

Вы можете проверить производительность вашего сайта Magento

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

FPC Потепление

И вы можете подогреть FPC, который будет попадать на каждый URL в sitemap.xml.

./wfpc -w http://mymagentosite.com/sitemap.xml

Вы также можете установить задержку между запросами, если хотите, вот задержка в 1 секунду между запросами.

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

Тестовый режим выбирает только 10 URL случайным образом, поэтому, как только вы согреете свой FPC, вы можете запустить тестовый режим, чтобы узнать, какую разницу имеет FPC!

мысли

Лично я думаю, что теплее имеет смысл ... На небольшом сайте с 40 страницами время загрузки сокращается примерно вдвое с помощью FPC. На большом сайте с почти 40 000 продуктов, использующими Lesti_FPC с APCu в качестве бэкэнда, я использую чуть более 200 МБ для кеша, чего, честно говоря, нет на производственном сервере 8 ГБ.

quickshiftin
источник