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