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