Quando uma cache de proxy partilhada ajuda um crawler
Avalie recursos repetidos, frescura e pedidos reais do crawler antes de esperar que uma cache forward-proxy partilhada melhore o débito.
Suponha que vários trabalhadores num navegador abrem páginas diferentes de um mesmo site. Essas páginas referem a mesma folha de estilos, logótipo e pacote de scripts. Uma cache forward partilhada pode tornar o primeiro pedido útil para trabalhadores posteriores quando as respostas podem ser reutilizadas.
Agora altere a carga: cada trabalhador descarrega apenas um documento HTML e nunca carrega os recursos associados. A folha de estilos comum continua no markup, mas nenhum trabalhador a pede. Não contribui em nada para a taxa de acertos da cache do proxy.
Comece pelos pedidos que o seu crawler faz realmente
Um navegador que renderiza uma página e um cliente HTTP que obtém o seu código-fonte criam conjuntos de pedidos diferentes. Inspecione esses conjuntos antes de escolher um desenho de cache.
| Carga de trabalho | Potencial de reutilização partilhada |
|---|---|
| Os trabalhadores obtêm repetidamente os mesmos ativos públicos | Útil quando as regras de frescura e de chave de cache o permitem |
| Cada pedido tem um URL ou variante de resposta única | Pouca sobreposição para reutilizar |
| Uma resposta precisa de revalidação antes de ser reutilizada | Pode poupar bytes de resposta mas ainda exige uma viagem à origem |
| Os trabalhadores já satisfazem pedidos a partir da sua cache local | Esses pedidos podem nunca chegar ao proxy partilhado |
A igualdade de URL por si só não basta. A política de frescura da resposta e os campos nomeados por Vary podem distinguir representações. Conteúdo privado, não armazenável ou autenticado necessita das regras aplicáveis de cache partilhada; não deve ser forçado num único resultado público apenas para aumentar a contagem de acertos.
Para o tráfego HTTPS CONNECT comum, o proxy forward transporta um túnel cifrado e não tem objetos HTTP no interior para guardar. Uma instalação com inspeção TLS tem um comportamento de confiança e processamento diferente. Inclua o modo real ao avaliar se a cache de objetos está disponível.
Um acerto de cache pode evitar uma obtenção na origem, enquanto uma falha continua a pagar o trabalho do intermediário. Compare bytes úteis concluídos, tráfego para a origem e latência para a carga prevista. O número de threads descreve a concorrência; não descreve quanto conteúdo reutilizável essas threads partilham.