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.
fonte
if (req.url ~ "\.(png|gif|jp(e?)g|avi|flv|mp(e?)g|mp4|mp3)"){return(pass);}em vcl_recv (). Basicamente, eu não quero armazenar em cache a mídia - mas definitivamente quero armazenar em cache html (php) e até js / css (teoria é que as imagens contribuem menos para o tempo de carregamento da página do que o layout).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?
fonte
Para conteúdos dinâmicos , alguns tipos, como cotações de ações, são alterados frequentemente (atualizados a cada segundo
SaaS serverde abackend server), mas podem ser consultados com mais frequência (dezenas de milhares desubscription clients):Nesse caso, o armazenamento em cache na
SaaS serveratualização por segundobackend serverspossibilita atender às consultas de dezenas de milhares desubscription users.Sem um cache no servidor SaaS, esse modelo simplesmente não funcionaria.
fonte
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
fonte