Acho que a maneira mais fácil de pensar sobre a eficácia e a implementação de Varnish é pensar em combinações. Cada variável cria exponencialmente mais combinações. Em suma, essas variáveis são: host, URI e cabeçalhos / cookies.
por exemplo. estes são objetos diferentes no cache de verniz
domain.com/search/?q=something
domain.com/search/?q=something&source=A
domain.com/search/?q=something&source=B
domain.com/search/?q=something&source=A + nocookie
domain.com/search/?q=something&source=A + cookie1
domain.com/search/?q=something&source=A + cookie2
domain.com/search/?q=something&source=B + nocookie
domain.com/search/?q=something&source=B + cookie1
domain.com/search/?q=something&source=B + cookie2
NO ENTANTO: Contanto que as fontes não variem muito, e desde que o servidor não seja responsável pela geração de conteúdo diferente com base na fonte, ele deverá ser semi-direto. usar o verniz ... mas somente se você fizer alguma manipulação primeiro.
Como você tem a capacidade de manipular grande parte da solicitação do cliente com o Varnish, é possível remover o & source = A ou & source = B do URI solicitado antes de enviá-lo ao servidor de back-end. Essencialmente, isso transforma todas essas solicitações:
domain.com/search/?q=something&source=A + nocookie
domain.com/search/?q=something&source=A + cookie1
domain.com/search/?q=something&source=A + cookie2
domain.com/search/?q=something&source=B + nocookie
domain.com/search/?q=something&source=B + cookie1
domain.com/search/?q=something&source=B + cookie2
apenas isso:
domain.com/search/?q=something
O que foi 6 misses e sem hits agora é 1 miss e 5 hits
Então, o cliente solicita isso do Verniz:
domain.com/search/?q=something&source=A + cookie1
e o Varnish realmente solicitam isso do back-end (por exemplo, Apache) para a primeira solicitação:
domain.com/search/?q=something
e, em seguida, é armazenado em cache para solicitações subsequentes (aumentando, assim, significativamente sua taxa de acertos). Isso é chamado de "normalização".
Então, é claro, o arquivo JavaScript estático fará seu trabalho referenciando as strings de consulta de URI e fazendo alguma manipulação de DOM (o que o Google Analytics faz) com base na string de consulta de origem.
Assim, para o cliente, o & source = A será mantido e o JavaScript poderá usá-lo de acordo; e desde que o JavaScript seja responsável por alterar dinamicamente o conteúdo, você não deverá ter problemas para retirá-los de todos ou da maioria dos cookies ou cadeias de consulta da sua solicitação antes que o Varnish envie a solicitação ao back-end.
Você também pode armazenar em cache suas solicitações XML, desde que sejam solicitações GET.
Basicamente, o nome do jogo com o Varnish é "normalizar" o pedido de backend para que URIs / cookies / cabeçalhos que não afetem o que é retornado do servidor sejam manipulados como normalizados antes de serem enviados para o servidor. backend
Reformatando o URI em verniz: link
Se você precisar armazenar o conteúdo em cache dinamicamente com base em um cookie, use o vcl_hash: link Isso, obviamente, diminui sua taxa de acertos, por isso é melhor passar essa funcionalidade para o JavaScript para manipular e informar ao Varnish para não armazenar em cache pontos de extremidade específicos: por exemplo,
// don't cache this endpoint, this content changes based on the referrer
if (req.url ~ '/ajax/get_referrer/') { return (pass); }
A única parte que não entendi na sua pergunta foi:
Cookie is also dropped so the next time the user returns the page checks if cookie exists, if yes, selects to show the correct conversion code in HTML.
Desde que o servidor de back-end não precise ver o cookie ou definir o cookie, isto é, desde que o JavaScript seja responsável por cuidar do trabalho do DOM, você deve ficar desimpedido. Observe que, se a 'origem / referenciador' for diferente por usuário, você também deve informar ao Varnish para não armazenar em cache nenhum nó de extremidade usado para obter os dados necessários.
Você também deve observar que você deve armazenar em cache somente solicitações GET e HEAD no verniz. Se sua pesquisa ou JavaScript usar POST ou qualquer outro tipo de solicitação, eles não deverão ser armazenados em cache.
Eu definitivamente recomendo fazer tudo em um servidor de desenvolvimento. Você terá muitos outros fatores a considerar, como o fornecimento de PDFs / vídeos / áudio (também conhecidos como solicitações de tubulação), ignorar páginas e muitas outras considerações exclusivas de sua situação.