Índice:
- Uma Introdução ao Verniz
- Noções básicas: imagens de cache
- O padrão: imagens e páginas de cache
- O padrão ++: aumentar a resiliência do servidor
- Uso avançado: criar um servidor Web resiliente em um ambiente distribuído
- Uma ferramenta poderosa
Quando se trata de desempenho do site, o Varnish é uma tecnologia quente. Com uma instalação e configuração simples, é possível aumentar o desempenho de qualquer site e servir até um milhão de páginas com apenas um pequeno servidor privado virtual., Mostrarei quatro configurações possíveis que ajudarão a melhorar o tempo de resposta do seu site, independentemente de você servir centenas, milhares ou milhões de páginas.
Uma Introdução ao Verniz
O Varnish-Cache é um acelerador da Web com o objetivo de armazenar em cache o conteúdo do site. É um projeto de código aberto que visa otimizar e acelerar o acesso a sites de forma não invasiva - sem alterar o código - e permitir que você coloque suas mãos em seu site.
Foram os criadores do Varnish Cache que o chamaram de acelerador da Web, porque seu objetivo principal é melhorar e acelerar o front-end de um site. O Varnish consegue isso armazenando cópias das páginas servidas pelo servidor Web em seu cache. Na próxima vez que a mesma página for solicitada, o Varnish enviará a cópia em vez de solicitar a página do servidor da Web, resultando em um tremendo aumento de desempenho.
Outro dos principais recursos do Varnish Cache, além de seu desempenho, é a flexibilidade de sua linguagem de configuração, a VCL. O VCL torna possível escrever políticas sobre como as solicitações recebidas devem ser tratadas. Nessa política, você pode decidir qual conteúdo deseja veicular, de onde deseja obtê-lo e como a solicitação ou resposta deve ser alterada.
Nos exemplos de configuração a seguir, mostrarei quais regras da VCL usar para atingir alguns objetivos, desde um simples armazenamento em cache de imagens e objetos estáticos, até o Varnish em um ambiente distribuído ou para que ele atue como um balanceador de carga.
Todos os exemplos a seguir são para o verniz 3.x. Observe que o Varnish 2.x usa sintaxe e regras diferentes; portanto, esses exemplos não são compatíveis com essa versão.
A seguir, estão os principais estados do Varnish, que usaremos no arquivo de configuração da VCL:
recv
Esta é a primeira função que é chamada ao receber uma solicitação. Aqui, podemos manipular a solicitação antes de verificar se ela está presente no cache. Se uma solicitação não puder ser colocada em um cache, o servidor backend ao qual a solicitação será enviada também poderá ser escolhido nesta fase.
passar
Podemos usar essa função quando queremos passar a solicitação ao servidor da Web e armazenar em cache a resposta.
tubo
Esta função ignora o Varnish e envia a solicitação ao servidor da Web.
olho para cima
Com uma pesquisa, o Varnish pede para verificar se a resposta está presente e válida no cache.
buscar
Essa função é chamada após a recuperação do conteúdo do back-end ser invocada por um passe ou uma falha.
Noções básicas: imagens de cache
Então, vamos ver um exemplo de configuração. Neste primeiro exemplo, apenas armazenaremos em cache as imagens e os arquivos estáticos, como arquivos CSS. Essa configuração é realmente útil quando você não conhece o site que deseja impulsionar, para poder decidir que todas as imagens, CSS e JavaScript são iguais para todos os usuários. Para distinguir os usuários, o protocolo HTTP usa cookies; portanto, temos que eliminá-los nesse tipo de solicitação para que sejam todos iguais para o Varnish:
sub vcl_recv{
if(req.url ~ " * \.(png|gif|jpg|swf|css|js)"{
unset req.http.cookie;
unset req.http.Vary;
return(lookup);
}
# strip the cookie before the image is inserted into cache.
sub vcl_fetch {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
unset beresp.http.set-cookie;
}
E é isso. Com este arquivo VCL, você pode armazenar em cache facilmente o conteúdo estático.
O padrão: imagens e páginas de cache
Normalmente, você não deseja apenas armazenar em cache o conteúdo estático do seu site, mas também deseja armazenar em cache algumas páginas dinâmicas geradas pelo servidor da Web, mas que são iguais para todos os usuários - ou pelo menos para todos os seus usuários anônimos. Comercial. Nesta fase, você deve saber escolher quais páginas podem ser armazenadas em cache e quais não.
Um bom exemplo é o Wordpress, um dos sistemas de gerenciamento de conteúdo mais usados. O Wordpress gera páginas de sites dinamicamente com PHP e consultas a um banco de dados MySQL. Isso é bom porque você pode atualizar facilmente seu site a partir da interface de administração com apenas alguns cliques, mas também é caro em termos de recursos utilizados. Por que executar o mesmo script PHP e consulta MySQL toda vez que um usuário entra na página inicial? Podemos usar o Varnish para armazenar em cache as páginas mais visitadas e obter resultados incríveis.
Estas são algumas regras que podem ser úteis em uma instalação do Wordpress:
sub vcl_recv{
# Let's make sure we aren't compressing already compressed formats.
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|mp3|mp4|m4v)(\?. * |)$") {
remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
remove req.http.Accept-Encoding;
}
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
}
sub vcl_miss {
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
}
if (req.url ~ "^/+.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.|)$") {
unset req.http.cookie;
set req.url = regsub(req.url, "\?.$", "");
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
}
sub vcl_fetch {
if (req.url ~ "^/$") {
unset beresp.http.set-cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset beresp.http.set-cookie;
}
}
Você pode ver que, neste exemplo, armazenamos em cache todas as páginas do nosso site, mas para aquelas que possuem "wp-admin" ou "wp-login" no URL, as strings são locais "especiais" usados para efetuar login no Wordpress como administrador. Como tal, queremos conversar diretamente com o servidor da Web e ignorar o cache do Varnish.
Naturalmente, se você usa o Drupal, o Joomla ou um site personalizado, é necessário alterar essas regras, mas o objetivo é sempre o mesmo: enviar todas as páginas dinâmicas e cache possível para o seu back-end.
O padrão ++: aumentar a resiliência do servidor
Em algum momento, os servidores Web ficam lentos porque têm uma carga alta. O verniz também pode ajudar. Podemos usar algumas diretivas especiais para dizer ao Varnish que evite conversar com o back-end se estiver inativo ou se estiver respondendo muito lentamente. Para esses casos, o Varnish usa a diretiva "graça".
Graça no escopo do verniz significa entregar objetos vencidos quando as circunstâncias o exigirem. Isso pode acontecer porque:
- O diretor de back-end selecionado está desativado
- Um encadeamento diferente já fez uma solicitação ao back-end que ainda não foi concluída.
sub vcl_recv {
if (req.backend.healthy) {
set req.grace = 30s;
} else {
set req.grace = 1h;
}
}
sub vcl_fetch {
set beresp.grace = 1h;
}
Essa configuração instrui o Varnish a testar o backend e aumentar o período de carência, se houver algum problema. O exemplo acima também apresenta a diretiva "req.backend.healthy", usada para verificar um back-end. Isso é realmente útil quando você tem vários back-ends, então vamos dar uma olhada em um exemplo mais avançado.
Uso avançado: criar um servidor Web resiliente em um ambiente distribuído
Este é o nosso arquivo de configuração final com todas as opções que vimos até agora e a definição de dois back-ends com alguma diretiva especial para o probe. É assim que o Varnish determina se um servidor da Web está ativo ou não.
.url
O Varnish fará solicitações para o back-end com este URL.
.tempo esgotado
Determina a rapidez com que a sonda deve terminar. Você deve especificar uma unidade de tempo com um número, como "0, 1 s", "1230 ms" ou até "1 h".
.intervalo
Quanto tempo de espera entre as pesquisas. Você deve especificar uma unidade de tempo aqui também. Observe que isso não é uma "taxa", mas um "intervalo". A taxa mais baixa de pesquisa é (.timeout + .interval).
.janela
Quantas das pesquisas mais recentes a serem consideradas ao determinar se o back-end é íntegro.
.limite
Quantas das últimas pesquisas do Windows devem ser boas para que o back-end seja declarado íntegro.
Agora podemos usar a diretiva "req.backend.healthy" e obter um resultado booleano que nos informa se os back-end estão ativos ou não.
#
# Customized VCL file for serving up a Wordpress site with multiple back-ends.
#
# Define the internal network subnet.
# These are used below to allow internal access to certain files while not
# allowing access from the public internet .
acl internal {
"10.100.0.0"/24;
}
# Define the list of our backends (web servers), they Listen on port 8080
backend web1 { .host = "10.100.0.1"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
backend web2 { .host = "10.100.0.2"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
# Define the director that determines how to distribute incoming requests.
director default_director round-robin {
{ .backend = web1; }
{ .backend = web2; }
}
# Respond to incoming requests.
sub vcl_recv {
set req.backend = default_director;
# Use anonymous, cached pages if all backends are down.
if (!req.backend.healthy) {
unset req.http.Cookie;
set req.grace = 6h;
} else {
set req.grace = 30s;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
# Always cache the following file types for all users.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
unset req.http.Cookie;
}
}
# Code determining what to do when serving items from the web servers.
sub vcl_fetch {
# Don't allow static files to set cookies.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
# beresp == Back-end response from the web server.
unset beresp.http.set-cookie;
}
# Allow items to be stale if needed.
set beresp.grace = 6h;
}
Uma ferramenta poderosa
Estes são apenas alguns exemplos que podem ajudá-lo a começar a usar o Varnish. Essa ferramenta é realmente poderosa e pode ajudá-lo a obter um excelente aumento de desempenho sem comprar mais hardware ou máquinas virtuais. Para muitos administradores de sites, esse é um benefício real.
