Por que armazenar em cache arquivos estáticos com o Varnish, por que não passar

Question

Eu tenho um sistema que executa nginx / php-fpm / verniz / wordpress e amazon s3.

Agora, observei muitos arquivos de configuração durante a configuração do sistema e, em todos eles, encontrei algo assim:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

Eu não entendo porque isso é feito. A maioria dos exemplos também executa o NginX como um servidor da web. Agora a questão é: por que você usaria o cache de verniz para armazenar em cache esses arquivos estáticos?

Faz muito mais sentido para mim apenas armazenar em cache os arquivos dinâmicos para que o php-fpm / mysql não seja muito afetado.

Estou correto ou estou sentindo alguma falta aqui?

UPDATE

Eu quero adicionar algumas informações à pergunta com base na resposta dada.

Se você tem um site dinâmico, onde o conteúdo realmente muda muito, chaching não faz sentido. Mas se você usar o WordPress para um site estático, por exemplo, isso pode ser armazenado em cache por longos períodos de tempo.

Dito isso, o mais importante para mim é conent estático . Eu encontrei um link com alguns testes e benchmarks em diferentes aplicativos de cache e aplicativos de servidores web.

link

O NginX é realmente mais rápido para obter seu conteúdo estático, por isso faz mais sentido apenas deixar passar. O NginX funciona muito bem com arquivos estáticos.

-

Além disso, na maior parte do tempo, o conteúdo estático nem mesmo está no próprio servidor da web. Na maioria das vezes, esse conteúdo é armazenado em um CDN em algum lugar, talvez no AWS S3, algo assim. Eu acho que o cache de verniz é o último lugar onde você quer ter seu conteúdo estático armazenado.

    

Answer 1

Existem algumas vantagens para o verniz. O primeiro que você nota é reduzir a carga em um servidor de backend. Normalmente, armazenando em cache o conteúdo que é gerado dinamicamente, mas raramente muda (comparado com a frequência com que é acessado). Tomando seu exemplo Wordpress, a maioria das páginas presumivelmente não muda com muita freqüência, e existem alguns plugins que existem para invalidar um cache de verniz quando a página muda (por exemplo, nova postagem, edição, comentário, etc). Portanto, você armazena o cache indefinidamente e invalida a alteração - o que resulta na carga mínima para o servidor de back-end.

O artigo vinculado não obstante, a maioria das pessoas sugere que o Varnish tem melhor desempenho que o Nginx se configurado corretamente - embora (e eu realmente odeie admitir) - meus próprios testes parecem concordar que o nginx pode servir um arquivo estático mais rápido do que verniz (por sorte, não uso verniz para esse fim). Eu acho que o problema é que se você acabar usando o verniz, você adicionou uma camada extra à sua configuração. Passar por essa camada extra para o servidor de back-end sempre será mais lento do que apenas servir diretamente do back-end - e é por isso que permitir que o Varnish armazene em cache seja mais rápido - você economiza um passo. A outra vantagem está na frente do disco-io. Se você configurar o verniz para usar o malloc, você não atingirá o disco, o que o deixará disponível para outros processos (e normalmente aceleraria as coisas).

Eu acho que seria necessário um melhor benchmark para realmente avaliar o desempenho. Solicitar repetidamente o mesmo arquivo único aciona os caches do sistema de arquivos que começam a desviar o foco dos próprios servidores web. Um benchmark melhor usaria cerco com alguns milhares de arquivos estáticos aleatórios (possivelmente até mesmo dos logs do seu servidor) para simular o tráfego realístico. Indiscutivelmente, como você mencionou, tornou-se cada vez mais comum descarregar conteúdo estático em um CDN, o que significa que o Varnish provavelmente não o estará servindo para começar (você menciona o S3).

Em um cenário do mundo real, você provavelmente priorizará seu uso de memória - conteúdo dinâmico primeiro, pois é o mais caro para gerar; então pequeno conteúdo estático (por exemplo, js / css) e, por último, imagens - você provavelmente não armazenaria em cache outras mídias na memória, a menos que você tenha uma boa razão para fazê-lo. Neste caso, com o Varnish carregando arquivos da memória e nginx carregando-os do disco, o Varnish provavelmente terá um desempenho superior ao nginx (note que os caches do nginx são apenas para proxy e fastCGI, e aqueles, por padrão, são baseados em disco - embora seja possível usar nginx com memcached).

(Meu rápido - muito difícil, não ter credibilidade - teste mostrou nginx (direto) foi o mais rápido - vamos chamá-lo 100%, verniz (com malloc) foi um pouco mais lento (cerca de 150%) e nginx atrás de verniz (com passe) foi o mais lento (cerca de 250%). Isso fala por si - tudo ou nada - adicionando o tempo extra (e processamento) para se comunicar com o backend, simplesmente sugere que se você estiver usando verniz, RAM de sobra, você pode muito bem armazenar em cache tudo o que puder e servi-lo a partir do verniz, em vez de voltar ao nginx.

    

Answer 2

Acho que você pode estar perdendo alguma coisa.

Por definição, os arquivos dinâmicos são alterados. Normalmente, eles mudam fazendo algum tipo de consulta de banco de dados que afeta o conteúdo da página sendo entregue ao usuário. Portanto, você não deseja armazenar em cache o conteúdo dinâmico. Se você fizer isso, ele simplesmente se tornará conteúdo estático e, provavelmente, conteúdo estático com conteúdo incorreto.

Como um exemplo simples, digamos que você tenha uma página com o nome de usuário do usuário logado no topo da página. Cada vez que a página é carregada, uma consulta de banco de dados é executada para determinar qual nome de usuário pertence ao usuário conectado, solicitando a página, o que garante que o nome adequado seja exibido. Se você tivesse que armazenar em cache esta página, a consulta ao banco de dados não aconteceria e todos os usuários verão o mesmo nome de usuário na parte superior da página e provavelmente não será o nome de usuário deles. Você precisa que essa consulta aconteça em cada carregamento de página para garantir que o nome de usuário correto seja exibido para cada usuário. Portanto, não pode ser armazenado em cache.

Estenda essa lógica para algo um pouco mais problemático, como permissões de usuário, e você pode ver por que o conteúdo dinâmico não deve ser armazenado em cache. Se o banco de dados não for atingido por conteúdo dinâmico, o CMS não tem como determinar se o usuário que está solicitando a página tem permissões para ver essa página.

O conteúdo estático é, por definição, o mesmo para todos os usuários. Portanto, não é necessária nenhuma consulta ao banco de dados para personalizar essa página para cada usuário, portanto, faz sentido armazená-lo em cache para eliminar consultas de banco de dados desnecessárias. As imagens são um ótimo exemplo de conteúdo estático - você quer que todos os usuários vejam a mesma imagem de cabeçalho, os mesmos botões de login, etc., então eles são excelentes candidatos para o armazenamento em cache.

No seu snippet de código acima, você vê um snippet VCL Varnish muito típico que força o cache de imagens, css e javascript. Por padrão, o Varnish não armazenará em cache qualquer solicitação com um cookie. A lógica é que, se houver um cookie na solicitação, deve haver algum motivo para o servidor precisar desse cookie, de forma que seja necessário no backend e deve ser passado pelo cache. Na realidade, muitos CMSes (Drupal, Wordpress, etc) anexam cookies a quase tudo, seja ou não necessário, por isso é comum escrever VCL para retirar os cookies do conteúdo que é conhecido como estático, o que faz com que o Varnish seja cache isso.

Faz sentido?

    

Answer 3

Para conteúdo dinâmico , algum tipo de cotação de ações é alterado com frequência (atualizado a cada segundo em SaaS server de backend server ), mas pode ser consultado ainda mais frequentemente (por dezenas de milhares de subscription clients ):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

Nesse caso, armazenamento em cache na atualização de SaaS server por segundo de backend servers torna possível satisfazer as consultas de dezenas de milhares de subscription users .

Sem um cache no servidor SaaS, esse modelo simplesmente não funcionaria.

    

Answer 4

O armazenamento em cache de arquivos estáticos com o Verniz se beneficiaria em termos de descarregamento do Nginx. Claro, se você tiver muitos arquivos estáticos para armazenar em cache, isso desperdiçará memória RAM. No entanto, o Varnish tem um bom recurso - ele suporta vários back-ends de armazenamento para o seu cache.

Para arquivos estáticos: cache para HDD Para tudo mais: cache para RAM.

Isso deve fornecer mais informações sobre como implementar esse cenário: link