Ми просто ні - зовсім. Колись. Ми будемо говорити про це знову і знову, але
Кешування! = Продуктивність
Ваш сайт повинен бути швидким без додавання FPC (або лаку за цим фактом). Завжди буде час, коли вміст не буде загрунтовано (ваш сценарій вище).
У завантаженому магазині час завантаження сторінки за допомогою 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, який потрібно.
Тож якщо ви хочете, щоб вміст мав 3600s TTL, сканування може бути в 4 рази повільніше - тобто. Лише 25% процесора присвячено скануванню. Це дуже багато ресурсів для того, щоб залишити вміст категорії грунтовним - на цьому етапі ми навіть не враховували продукти, пошукові терміни чи додаткові перегляди магазину.
Насправді, лише перегляд розміру комбінацій у catalog_url_rewritesтаблиці (який навіть не враховує параметри шаруватої навігації) дасть уявлення про те, скільки URL-адрес ви можете сканувати.
Кожен магазин, безумовно, буде іншим, але те, що я намагаюсь вразити додому, - це те, що сканування сайту для просування FPC не є практичним. Просто переконайтеся, що ваш магазин швидко починається .
Де FPC корисний
Там, де переваги FPC грають, є у дуже завантаженому магазині - там, де у вас справді високий рівень трафіку, а кеші, природно і постійно, ґрунтуються лише одним падінням ноги.
Тоді FPC починає грати, зменшуючи накладні витрати на інфраструктуру для часто запитуваного контенту - скорочуючи ті повторні дзвінки до сервера Magento.
Тож ми виявили, що FPC чудово розгортається, коли у вас дуже високий рівень трафіку - не для скорочення часу завантаження сторінки - а для зменшення використання ресурсів.
Кого байдуже, я все одно хочу повзати
Ну, тоді у вас є два варіанти
- Сканування з шаблону (наприклад, мапа сайту)
- Витягуйте посилання сторінки за сторінкою та скануйте кожну
І є багато комунальних служб, які роблять і те, і інше, це я знаю
- маг-перфтест
- HTTrack
- Гайка
- Сфідер
- 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% CPU або середнє завантаження 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