Eu tenho um sistema rodando 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 parecido com isto:

    /* 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 por que isso é feito. A maioria dos exemplos também executa o NginX como um servidor da web. Agora, a pergunta é: 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 atingido tanto.

Estou correto ou estou faltando alguma coisa aqui?

ATUALIZAR

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, o chaching não faz sentido. Mas se você usa o WordPress para um site estático, por exemplo, isso pode ser armazenado em cache por longos períodos de tempo.

Dito isto, mais importante para mim é o conteúdo estático . Encontrei um link com alguns testes e referências em diferentes aplicativos de cache e aplicativos de servidor da web.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

O NginX é realmente mais rápido na obtenção de seu conteúdo estático, por isso faz mais sentido apenas deixá-lo passar. O NginX funciona muito bem com arquivos estáticos.

-

Além disso, na maioria das vezes o conteúdo estático não está presente no servidor da web. Na maioria das vezes, esse conteúdo é armazenado em uma CDN em algum lugar, talvez no AWS S3, algo assim. Eu acho que o cache de verniz é o último lugar em que você deseja que seu conteúdo estático seja armazenado.

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

Não obstante, o artigo vinculado, a maioria das pessoas sugere que o Varnish tem um desempenho melhor que o Nginx se configurado corretamente - embora (e eu odeio admitir) - meus próprios testes parecem concordar que o nginx pode servir um arquivo estático mais rápido que o verniz ( felizmente, não uso verniz para esse fim). Penso que o problema é que, se você acabar usando o Varnish, adicionou uma camada extra à sua configuração. A passagem dessa camada extra para o servidor de back-end sempre será mais lenta do que apenas servir diretamente a partir do back-end - e é por isso que permitir que o Varnish faça cache seja mais rápido - você salva uma etapa. A outra vantagem está na frente do disk-io. Se você configurar o verniz para usar o malloc, não acerte o disco, o que o deixa disponível para outros processos (e normalmente acelera).

Eu acho que seria necessário um benchmark melhor para realmente medir 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 da web. Uma referência melhor usaria o cerco com alguns milhares de arquivos estáticos aleatórios (possivelmente até nos logs do servidor) para simular tráfego realista. Indiscutivelmente, como você mencionou, tornou-se cada vez mais comum transferir conteúdo estático para uma CDN, o que significa que o Varnish provavelmente não o servirá para começar (você mencionou S3).

Em um cenário do mundo real, você provavelmente priorizaria o uso da memória - primeiro o conteúdo dinâmico, pois é o mais caro de gerar; depois, um pequeno conteúdo estático (por exemplo, js / css) e, finalmente, imagens - você provavelmente não armazenaria em cache outras mídias na memória, a menos que tenha realmente um bom motivo para fazê-lo. Nesse caso, com o Varnish carregando arquivos da memória e o nginx carregando-os do disco, o Varnish provavelmente superará o nginx (observe que os caches do nginx são apenas para proxying e fastCGI, e esses, por padrão, são baseados em disco - embora, seja possível usar o nginx com o memcached).

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

Eu acho que você pode estar perdendo alguma coisa.

Por definição, os arquivos dinâmicos mudam. Normalmente, eles mudam fazendo algum tipo de consulta ao banco de dados que afeta o conteúdo da página que está sendo veiculada ao usuário. Portanto, você não deseja armazenar em cache conteúdo dinâmico. Se o fizer, 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 conectado na parte superior da página. Cada vez que a página é carregada, uma consulta ao banco de dados é executada para determinar qual nome de usuário pertence ao usuário conectado que solicita a página, o que garante que o nome correto seja exibido. Se você armazenasse esta página em cache, a consulta ao banco de dados não aconteceria e todos os usuários veriam o mesmo nome de usuário na parte superior da página e provavelmente não será o nome de usuário. Você precisa que essa consulta ocorra a cada carregamento da página para garantir que o nome de usuário apropriado seja exibido para cada usuário. Portanto, não é armazenável 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 encontrado para conteúdo dinâmico, o CMS não terá 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, nenhuma consulta ao banco de dados precisa ocorrer para personalizar essa página para cada usuário, portanto, faz sentido armazenar em cache para eliminar consultas desnecessárias ao banco de dados. As imagens são realmente um excelente exemplo de conteúdo estático - você deseja que todos os usuários vejam a mesma imagem de cabeçalho, os mesmos botões de login etc., portanto, são excelentes candidatos ao cache.

No seu snippet de código acima, você vê um snippet VCL Varnish muito típico que força imagens, css e javascript a serem armazenados em cache. Por padrão, o Varnish não armazena em cache nenhuma solicitação com um cookie. A lógica é que, se houver um cookie na solicitação, deve haver algum motivo pelo qual o servidor precise desse cookie, para que seja necessário no back-end e seja 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 de conteúdo que é conhecido por ser estático, o que faz com que o Varnish faça cache isto.

Faz sentido?

Para conteúdos dinâmicos , alguns tipos, como cotações de ações, são alterados frequentemente (atualizados a cada segundo SaaS serverde a backend server), mas podem ser consultados com mais frequência (dezenas de milhares de subscription clients):

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

Nesse caso, o armazenamento em cache na SaaS serveratualização por segundo backend serverspossibilita atender às consultas de dezenas de milhares de subscription users.

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

O armazenamento em cache de arquivos estáticos com o Varnish se beneficiaria em termos de descarregamento do Nginx. Obviamente, se você tiver muitos arquivos estáticos para armazenar em cache, ela desperdiçará RAM. No entanto, o Varnish possui um recurso interessante - ele suporta vários back-ends de armazenamento para seu cache.

Para arquivos estáticos: cache para HDD Para todo o resto: cache para RAM.

Isso deve fornecer mais informações sobre como implementar esse cenário: http://www.getpagespeed.com/server-setup/varnish-static-files-cache