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. 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. 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. 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.