Коли спільний кеш проксі допомагає краулеру
Оцініть повторювані ресурси, свіжість і фактичні запити краулера, перш ніж очікувати, що спільний forward-кеш проксі підвищить пропускну здатність.
Припустімо, кілька браузерних воркерів відкривають різні сторінки одного сайту. Ці сторінки посилаються на ту саму таблицю стилів, логотип і пакет скриптів. Спільний forward-кеш може зробити перший запит корисним для наступних воркерів, коли відповіді можна використати повторно.
Тепер змініть навантаження: кожен воркер завантажує лише один HTML-документ і ніколи не завантажує пов'язані ресурси. Спільна таблиця стилів досі є в розмітці, але жоден воркер її не запитує. Вона нічого не додає до частки влучань у кеш проксі.
Почніть із запитів, які ваш краулер справді робить
Браузер, що візуалізує сторінку, і HTTP-клієнт, що забирає її вихідний код, створюють різні набори запитів. Дослідіть ці набори, перш ніж обирати схему кешування.
| Навантаження | Потенціал спільного повторного використання |
|---|---|
| Воркери багаторазово забирають ті самі публічні ресурси | Корисно, коли це дозволяють правила свіжості та ключа кешу |
| Кожен запит має унікальний URL або варіант відповіді | Мало перетинів для повторного використання |
| Відповідь потребує повторної перевірки перед повторним використанням | Може заощадити байти відповіді, але все одно потребує звернення вгору |
| Воркери вже обслуговують запити з власного локального кешу | Ці запити можуть взагалі не дійти до спільного проксі |
Самої рівності URL недостатньо. Політика свіжості відповіді та поля, названі Vary, можуть розрізняти подання. Приватний, незбережуваний або автентифікований вміст потребує застосовних правил спільного кешу; його не можна примусово зводити до одного публічного результату лише заради збільшення кількості влучань.
Для звичайного трафіку HTTPS CONNECT forward-проксі несе зашифрований тунель і не має всередині HTTP-об'єктів для кешування. Розгортання з інспекцією TLS має іншу поведінку довіри й обробки. Враховуйте фактичний режим, оцінюючи доступність кешування об'єктів.
Влучання в кеш може уникнути звернення вгору, а промах усе одно оплачує роботу посередника. Порівняйте завершені корисні байти, трафік угору та затримку для передбачуваного навантаження. Кількість потоків описує паралельність; вона не описує, скільки повторно використовуваного вмісту ці потоки поділяють.