Varnish: Uma camada de velocidade

O objetivo deste trabalho é apresentar ao leitor a ferramenta de proxy reverso Varnish, mostrar suas principais características e averiguar seu desempenho através de testes de benchmark. Nesta última fase foram feitos testes comparativos entre o Varnish e o Squid, em que ficou patente do desempenho superior do Varnish em todos os testes executados.

[ Hits: 67.282 ]

Por: Perfil removido em 10/05/2010


Introdução



Segundo Tim O'Reilly [1], o termo Web 2.0 nasceu em 2004 numa sessão de brainstorm entre os especialistas da O'Reilly e da Media Live Internacional. Este termo designaria diversas mudanças que estavam acontecendo na Internet e que a transformariam radicalmente. Para algumas pessoas, no centro desta revolução estava a tecnologia Ajax, para outros, uma maior interatividade ou mesmo colaboração.

O fato é que, a partir desse evento, a Internet sofreu um novo boom de aplicações para oferecer todo tipo de serviço colaborativo. Aplicações antes quase estáticas ganharam vida, disparando requisições Ajax para todo o planeta, solicitando mais interação e colaboração.

Do outro lado da linha, servidores Web se viram abarrotados de requisições ininterruptas, solicitando atualizações de caixa de email, os mais novos comentários, a cotação das ações. Serviços Web como blogs, fóruns e wikis se tornaram aplicações completas e pesadas que, de um lado, permitiam a um completo leigo gerir suas postagens na Web, mas, de outro, oneravam severamente os recursos do servidor.

Questões como escalabilidade e disponibilidade se tornam problemas complicados e urgentes. Okama [2] cita que normalmente a cada requisição GET no protocolo HTTP 1.1 é necessário se fazer vários acessos a banco de dados e executar muitos códigos em alguma linguagem de script. Assim que a requisição é entregue, todo esse trabalho é jogado fora e recomeçado na próxima requisição.

Soluções de cache e aceleração de processamento para os mais diversos tipos de aplicação se tornaram o assunto da vez. O Grupo Brasileiro de Usuários FreeBSD - FUG-BR [3] alerta que embora existam diversos sistemas de cache para linguagens especificas como o PHP, esses aceleradores não são de propósito geral, não funcionam para Zope-Plone, Java ou ASP em um mesmo momento. Para esses casos, FUG-BR aponta como solução adequada a utilização de sistemas de proxy reversos.

Tipicamente, um serviço de proxy é utilizado para compartilhar serviços de internet através de varias máquinas. Todas as requisições Web dos clientes são direcionadas para esse serviço, para que este decida se deve responder à requisição com algum objeto de seu cache ou se deverá enviá-la para algum servidor na Internet.

Diagrama de funcionamento do proxy
No Wikipédia [4] encontramos a definição de proxy reverso quando colocamos um serviço de proxy em frente a um servidor de rede, de forma que todas as requisições direcionadas a este servidor tenham de passar pelo serviço de proxy. Tipicamente, sistemas de proxy reversos são utilizados à frente de servidores Web. Como o serviço de proxy reverso armazena as resposta das requisições em seu cache para responder a futuras requisições, o resultado é que ele termina por acelerar o tempo de resposta.

Diagrama de funcionamento do proxy reverso
FUG-BR aponta que, em 2006, existiam duas principais soluções em proxy reverso com licenças livres no mercado: utilizava-se um módulo do apache para fazer o trabalho ou então utilizava-se o sistema de proxy Squid.

Numa análise a respeito destas soluções, Poul-Henning Kamp [5] aponta que o Squid apresenta diversos problemas arquiteturais. Em 1975, quando começou a ser desenvolvido, computadores eram formados basicamente de CPU, armazenamento interno e armazenamento externo, mas atualmente esta definição já não é cabível. Computadores atuais são formados por um número indefinido de cores ligados a um número variável de sistemas de cache e barramentos para dispositivos de armazenamento virtualizados.

O Squid possui duas configurações principais, que dizem respeito a quanta memória volátil e quanto espaço em disco o proxy deverá utilizar. Kamp [6] descreve diversos problemas de desempenho que o Squid apresenta quando tenta controlar o gerenciamento da memória de forma independente do Kernel.

Um dos maiores problemas citados se dá quando o Squid armazena objetos na memória volátil e, depois de algum tempo inativos, são jogados em disco pelo Kernel. Quando o Squid torna a requisitá-los, faz-se necessário que o Kernel retorne o objeto para a memória volátil e somente depois libere os objetos para o Squid, causando assim um grande retrabalho.

Arquiteturas do Squid e do Varnish
Quando Kamp [5] analisa a utilização de um módulo Apache como proxy, o conceito do analista é que o sistema não apresenta um bom desempenho, por sua arquitetura não ter sido originalmente pensada para funcionar como proxy. Outro problema indicado é a falta de controle dos objetos em cache.

Segundo FUG-BR [3], foi a partir desta análise que, em meados de 2006, a VG Multimédia se juntou ao Grupo de Usuários Unix da Noruega para financiar a construção de um novo sistema de proxy que conseguisse ter um desempenho e arquitetura melhores que a do Squid. Mas a maior aquisição do projeto certamente foi a de Poul-Henning Kamp como arquiteto e codificador do Varnish, velho conhecido da comunidade FreeBSD. Esse analista trabalhou muitos anos no Kernel do FreeBSD além de ter em seu currículo a participação em projetos de renome como a implementação do algoritmo MD5.

O resultado desta empreitada foi a publicação, em 6 meses, da primeira versão do Varnish. Os testes de benchmark apresentavam um aumento no desempenho de cerca de 600% em relação ao Squid. Segundo depoimento de Anders Berg, da VG Multimédia [7], com a utilização desse novo sistema, eles conseguiram trocar 12 servidores com o Squid para somente 2 com o Varnish. Posteriormente, em 2007, o código da aplicação foi reescrito na versão 2.0, aumentando ainda mais o desempenho e estabilidade deste proxy.

Rapidamente diversos grandes sites têm implementado essa solução em sua arquitetura. Hagelund [8], Mullenweg [9] e Schofmann [10] citam como sites que utilizam o Varnish: o sistema de buscas do Twitter, o Globo.com, Wordpress.com e o CreativeCommons.org.

Este trabalho se divide em duas partes. A primeira parte tem como objetivo introduzir o leitor nas principais características e funcionalidades do Varnish. Na segunda parte consta a realização de testes de Benchmark para averiguar o desempenho desta solução quando utilizada como cache.

    Próxima página

Páginas do artigo
   1. Introdução
   2. Parte 1 - Características do Varnish
   3. Parte 2 - Testes de benchmark
   4. Conclusão
Outros artigos deste autor

Apache 2.2 - Introdução ao módulo mod_rewrite

Passos essenciais para configurar seu modem 3G no Linux

Básico sobre tratamento de exceções em Python 3.4

Pesquisa com slocate, locate e updatedb

Fingerprint-GUI (solução para leitores biométricos) no Ubuntu

Leitura recomendada

Roteando duas sub-redes com servidores

Compartilhando internet via rádio entre um servidor Linux e clientes Windows

Verificando a velocidade ADSL contratada (Velox)

Conhecendo e testando vários navegadores de Internet

Virtual Host no CentOS 7

  
Comentários
[1] Comentário enviado por tomassoni em 12/05/2010 - 14:10h

Muito legal.
Gostaria de saber se você já o utilizou na prática, se teria um exemplo de regras.

[2] Comentário enviado por removido em 12/05/2010 - 14:39h

Participei de alguns testes na época do lançamento do Blog do Planalto em que pudemos por a prova esta ferramenta em uma rede de alta velocidade. Existem varios exemplos de configuração no site do projeto http://varnish-cache.org, mas depende do soft que for utilizar. Por exemplo, utilizei com um sistema de blogs wordpress/buddypress e na epoca eu checava a existência de um cookie para definir se iria fazer cache.

[3] Comentário enviado por Gilmar_GNU/Slack em 13/05/2010 - 14:00h

TO curtindo o lance de aprender sobre o varnish.
Pois eu estava lá na palestra na Area 1.
O Varnish tem uma vantagem bem interessante em cima do Squid.

[4] Comentário enviado por dolivervl em 13/05/2010 - 18:42h

Muito bom, eu estava procurando um artigo desse aqui no VOL há algum tempo atrás, mas não encontrei. Hoje já tenho meu proxy com varnish rodando.

[5] Comentário enviado por jr.jorro em 14/05/2010 - 14:34h

E para controle de internet ? Num ambiente que envolve muitos usuários ?

Gostaria de saber as vatagens do Squid sob o varnish e as desvantagens do varnish. Se alguém puder me dar uma luz, agradeço.

[6] Comentário enviado por removido em 14/05/2010 - 15:15h

Serviço de hospedagem de sites tam uma fila de atendimento, se o seu servidor consegue atender rapidamente, esta fila se mantem pequena, se ele engasga ela cresce e derruba o serviço. O varnish serve para acelerar o atendimento às requisições mantendo as páginas em memoria.

O squid perde de longe para esta belezinha, ele não consegue gerenciar corretamente a memoria nem distribuir seus jobs pelos núcleos do computador.

[7] Comentário enviado por mosoli em 14/05/2010 - 17:19h

Cara!
Excelente artigo!

[8] Comentário enviado por schenkmh em 25/05/2010 - 09:17h

Estou usando a versão 2.1 do Varnish baixada do repositório do Ubuntu. Segui algumas configurações sugeridas no site http://varnish-cache.org, porém são para versão 2.0 e estou enfrentando algumas dificuldades devido a interpretação de comandos por esta versão. Não tenho grande experiência nas linguagens C e Perl. Alguém pode me ajudar? Segue o erro retornado:

root@marco-desktop:/home/marco# varnishd -a :80 -T localhost:6082 -f /etc/varnish/teste.vcl -s file,/var/cache/varnish.cache,512M
storage_file: filename: /var/cache/varnish.cache size 512 MB.
Message from VCC-compiler:
Invalid assignment operator ';' only '=' is legal for strings
Message from C-compiler:
./vcl.1P9zoqAU.c: In function ‘VGC_function_vcl_fetch’:
./vcl.1P9zoqAU.c:736: error: expected ‘)’ before ‘;’ token
./vcl.1P9zoqAU.c:738: error: invalid use of void expression
./vcl.1P9zoqAU.c:738: error: expected ‘;’ before ‘}’ token
Running C-compiler failed, exit 1
VCL compilation failed

Valeu!

[9] Comentário enviado por removido em 25/05/2010 - 09:48h

Fiz a instalação do Varnish 2.1 no Ubuntu Lucid e a instalação padrão esta funcionando blz, tb testei este comando q vc enviou mudando somente o aquivo teste.vcl para default.vcl q é o padrão instalado e também funcionou normal. A falha esta em seu vcl, coloque o conteúdo padrão nele conforme abaixo e teste novamente para ver se funciona. Qualquer coisa meu mail é alexandrehaguiar arroba gmail.com.

backend default {
.host = "127.0.0.1";
.port = "8080";
}

[10] Comentário enviado por schenkmh em 25/05/2010 - 10:15h

Olá Alexandre

Não funcionou. Enviei um e-mail com meu arquivo vcl, ok!
Obrigado pela ajuda!

[11] Comentário enviado por pokado em 17/08/2010 - 14:55h

tinha lido sobre as vantagens dele sobre o squid... mas será que tem como fazer ele trabalhar como cache web normal (nao reverso) ?

[12] Comentário enviado por removido em 17/08/2010 - 17:11h

Ele foi feito para trabalhar especificamente como proxy reverso e não tem outros recursos que o squid possui necessários para uma ferramenta de proxy.

[13] Comentário enviado por FireBird em 10/05/2011 - 16:41h

Cara... Onde fica e como faço pra limpar o cache do varnish? Sabe me falar?

[14] Comentário enviado por fabriciocscte em 18/02/2013 - 17:21h

Eu queria saber se utilizando o varnish com a seguinte configuração eu tenho um acréscimo na segurança.
Eu tenho muitos ataques a sites wordpress, então pensei em isolar os clientes em um servidor X e liberar o acesso para o servidor Y que hospeda o varnish. Assim, apenas o servidor X terá acesso aos servidor Y(meus clientes wordpress).

Como esses ataques acontecem de forma automática e infectam com malware, queria saber se essa configuração isola os PHPs dosmeus sites wordspress.


vlw

[15] Comentário enviado por removido em 18/02/2013 - 21:09h

O varnish pode ajudar em ataques de negação de serviço mas não em ataques com bots.

Você pode tentar proteger as páginas wp-login e wp-admin com uma autenticação básica adicional para evitar que os scripts funcionem... pode até interligar esta autenticação básica com um sistema de firewall como o csf (http://configserver.com/cp/csf.html) e fazer com que o usuário fique bloqueado apos certo número de erros. Cuidado no entanto para não bloquear seus clientes;)

O melhor mesmo seria bloquear estes links para acesso somente por uma rede especifica...


Contribuir com comentário