Quando una cache proxy condivisa aiuta un crawler
Valutate risorse ripetute, freschezza e richieste reali del crawler prima di attendervi che una cache forward-proxy condivisa migliori la velocità effettiva.
Supponiamo che diversi worker in un browser aprano pagine diverse dello stesso sito. Quelle pagine fanno riferimento allo stesso foglio di stile, logo e bundle di script. Una cache forward condivisa può rendere utile la prima richiesta ai worker successivi quando le risposte sono riutilizzabili.
Ora cambiate il carico: ogni worker scarica solo un documento HTML e non carica mai le risorse collegate. Il foglio di stile comune è ancora presente nel markup, ma nessun worker lo richiede. Non contribuisce in alcun modo al tasso di successo della cache del proxy.
Iniziate dalle richieste che il vostro crawler effettua davvero
Un browser che renderizza una pagina e un client HTTP che ne recupera il sorgente creano insiemi di richieste diversi. Esaminate questi insiemi prima di scegliere un progetto di cache.
| Carico di lavoro | Potenziale di riutilizzo condiviso |
|---|---|
| I worker recuperano ripetutamente gli stessi asset pubblici | Utile quando le regole di freschezza e chiave di cache lo consentono |
| Ogni richiesta ha un URL o una variante di risposta unica | Poco sovrapposizione da riutilizzare |
| Una risposta richiede rivalidazione prima del riutilizzo | Può risparmiare byte di risposta pur richiedendo un viaggio verso l'origine |
| I worker soddisfano già le richieste dalla propria cache locale | Queste richieste potrebbero non raggiungere mai il proxy condiviso |
La sola uguaglianza dell'URL non basta. La politica di freschezza della risposta e i campi nominati da Vary possono distinguere le rappresentazioni. Contenuti privati, non memorizzabili o autenticati richiedono le regole applicabili delle cache condivise; non vanno forzati in un unico risultato pubblico solo per aumentare il numero di successi.
Per il normale traffico HTTPS CONNECT, il proxy forward trasporta un tunnel cifrato e non ha oggetti HTTP all'interno da memorizzare. Un deployment con ispezione TLS ha un comportamento di fiducia ed elaborazione diverso. Includete la modalità reale quando valutate se la cache degli oggetti è disponibile.
Un successo della cache può evitare un recupero a monte, mentre una mancata risposta paga comunque il lavoro dell'intermediario. Confrontate byte utili completati, traffico verso monte e latenza per il carico previsto. Il numero di thread descrive la concorrenza; non descrive quanto contenuto riutilizzabile quei thread condividono.