Мы просто не - вообще. Когда-либо. Мы будем говорить это снова и снова, но
Кэширование! = Производительность
Ваш сайт должен быть быстрым без добавления FPC (или Varnish для этого факта). Всегда будет время, когда контент не заполнен (ваш сценарий выше).
В незагруженном магазине время загрузки страницы с FPC не должно быть намного более впечатляющим, чем без FPC; Magento вполне может рассчитывать на < 400msзагрузку страниц на стандартных кешах (на страницах категории / продукта / поиска). FPC понизит это до < 80ms- но идет с оговорками.
- Информация об акциях / ценах устарела до аннулирования или истечения срока действия TTL
Новые товары / более релевантный поиск устарел до аннулирования или истечения срока действия TTL
и т.п.
Почему опора на FPC (или лак) - плохая идея
Если вы хотите постоянно проверять, заполнены ли кэши вручную, вероятно, есть несколько причин
- У вас недостаточно естественного шага, чтобы держать кешированные загрунтованными (см. «Где полезен FPC»)
- Ваш сайт слишком медленный без них
Вы не можете кэшировать все
Если вы берете магазин только с 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 отлично подходит для развертывания, когда у вас очень высокий уровень трафика - не для сокращения времени загрузки страницы - но для уменьшения использования ресурсов.
Кому интересно, я все равно хочу ползти
Ну, тогда у вас есть два варианта
- Сканирование по шаблону (например, карта сайта)
- Извлекайте ссылки постранично и сканируйте каждый
И есть много утилит, чтобы сделать оба из них, вот некоторые, о которых я знаю
- маг-perftest
- HTTrack
- Nutch
- Sphider
- 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