VARNISH-CACHE: VELOCIDADE E DISPONIBILIDADE PARA

APLICAÇÕES WEB

Rafael Vaz Pinto Toledo1

Eduardo Herbert Ribeiro Bona2

RESUMO: Com a disseminação de serviços e aplicações que utilizam a internet como

plataforma, e o número cada vez maior de usuários, a disponibilidade e a velocidade
das aplicações tornaram-se fatores que podem fadar um produto ao sucesso ou ao
fracasso. Em um ambiente tão heterogêneo como a internet, é impossível prever a
quantidade de usuários visitantes, assim como a experiência que cada um está tendo
ao acessar um serviço online. Com tantas variáveis para os administradores, a
escolha da suíte de softwares no servidor podem fazer a diferença, inclusive gerando
economia de recursos e maior estabilidade dos equipamentos envolvidos no
oferecimento de conteúdo online.

PALAVRAS-CHAVE: Varnish-Cache, Servidor WEB, Proxy, Internet

VARNISH-CACHE: SPEED AND AVAILABILITY FOR WEB

APPLICATIONS

ABSTRACT: With the spread of services and applications that use the Internet as
platform, and the increasing number of users, the availability and speed of applications
have become factors that may define if a product will reach success or failure. In a
heterogeneous environment such as the Internet, it is impossible to predict the amount
of guest visitors as well as the experience that everyone is having access to an online
service. With so many variables to administrators, the choice of server software suite
can make a difference, including generating resource savings and greater stability of
the equipment involved in providing online content.

KEYWORDS: Varnish-Cache, WEB Server, Proxy, Internet

1
Discente do curso de Sistemas para Internet do Centro Universitário de Maringá. rafamd@gmail.com
2
Docente do curso de Sistemas para Internet do Centro Universitário de Maringá. eduardobona@vivaweb.net
1. Introdução tempo entre a requisição efetuada pelo
cliente até a completa renderização da
A World Wide Web, ou WWW,
resposta do servidor pelo browser do
é hoje o principal serviço em
cliente. Tal tempo é necessário para
funcionamento na Internet, sendo
que a requisição seja enviada ao
responsável pela maioria do tráfego
servidor, para que o mesmo monte a
gerando dentro do conjunto de redes
resposta de acordo com as
que a constitui.
informações enviadas e retornar os
Mais que apenas um serviço, a pacotes de dados que serão
WWW tornou-se uma necessidade transferidos para o cliente através do
para os mais diversos segmentos da protocolo HTTP e interpretados pelo
economia, permitindo uma rápida browser.
comunicação, além de servir como
A latência também pode ser
base de operações para as mais
influenciada pelo tráfego da rede e o
diversas atividades envolvidas.
número de requisições simultâneas a
O conceito da WEB 2.0 que o servidor deve atender. Levando
(O’Reilly Media, 2004) elevou ainda em consideração que atualmente
mais a importância da Internet, diversos dispositivos permitem acesso
principalmente da WWW, que passou e utilizam a internet de alguma
de um simples meio de troca de maneira, é possível notar que não será
informações para uma plataforma, raro a ocasião em que um dos fatores
abrigando diversos serviços. A citados esteja influenciando
interatividade tornou-se um mantra negativamente na obtenção das
ecoado pelas diversas empresas informações desejadas.
envolvidas com a Internet, dando fruto
A tabela abaixo (Tabela 1) é
para diversos serviços, desde
parte da pesquisa elaborada pelo
informacionais como os portais de
NIC.BR (Núcleo de Informação e
notícias, passando pelos sociais e
Coordenação do Ponto BR) entre os
chegar aos mais recentes serviços
meses de Novembro de 2011 até
baseados na nuvem.
Janeiro de 2012, em que é possível
Apesar de todos os avanços verificar o percentual da presença dos
nesta área, um elemento presente em equipamentos de Informação e
todos os serviços é a latência, ou Comunicação nos domicílios

1
brasileiros. Para este artigo foram que atuam próximos aos servidores de
mantidos apenas os resultados dos conteúdo.
equipamentos que podem acessar de
alguma maneira a internet. Dentre os
equipamentos listados, os
computadores de mesa (com 36% de
presença), os consoles de videogame
(22%) e os computadores portáteis Figura 1: Diagrama do funcionamento de um servidor de

(18%) são aqueles que possuem maior proxy/cache.

probabilidade de gerar tráfego na rede. Os servidores de Proxy/Cache

(Figura 1) estão geralmente instalados
Equipamento Percentual
Televisão 98% na mesma rede em que os clientes,

Telefone Celular 87% sendo a primeira etapa antes que as

Desktop 36% requisições dos clientes trafeguem pela
Videogame 22% internet. Ele tem como funcionalidade
TV por Assinatura 20% armazenar cópias dos conteúdos
Computador Portátil 18% requisitados, a fim de acelerar a
Tabela 1: Proporção de domicílios que possuem
resposta em caso de novas requisições
equipamentos TIC
pelo conteúdo. O conteúdo é
Apesar da existência dos
armazenado por tempo determinado,
fatores apresentados, existem recursos
configurado pelo próprio administrador
para que este tempo seja reduzido. O
ou tomando como base os cabeçalhos
próprio protocolo HTTP provê
de resposta do servidor de conteúdo.
mecanismos de caching desde sua
versão 1.0, sendo que atualmente
oferece mecanismos mais flexíveis (1.1
utilizada atualmente).

Além do
implementado no protocolo HTTP, há
também tecnologias auxiliares, como
os servidores de proxy/cache que
atuam próximos aos clientes e os
servidores surrogate (ou proxy reverso)
mecanismo
Figura 2: Diagrama do funcionamento de um servidor
surrogate ou proxy reverso.
Ao contrário dos servidores de
proxy/cache, os surrogate (Figura 2)
atuam próximos aos servidores de
conteúdo (ou implementados

2
diretamente). Assim como no exemplo moderna, que tivesse acompanhado a
anterior, quando é recebido uma nova forma com que o hardware se
requisição, o surrogate armazena o desenvolveu ao longo dos anos, “Squid
resultado gerado pelo servidor, porém atuando como Reverse Proxy se
essa cópia pode ser usufruída por apresentou limitado demais em
qualquer requisição àquele objeto performance, por uma série de motivos
específico, reduzindo assim a carga do incluindo não fazer uso apropriado de
servidor de conteúdo. várias tecnologias disponíveis em
sistemas computacionais modernos.”
Este artigo tem como objetivo
(FUB-BR, 2006, Varnish-Cache –
implementar a ferramenta Varnish-
Servidor de Proxy Reverso com
Cache, um acelerador HTTP gratuito e
Cacheamento. http://tkme.in/to/MTU.
estudar o impacto dele em comparação
Acesso em 17 de Julho de 2012).
a um servidor web comum, sem esta
camada de velocidade. O capítulo 2 é Tal situação foi percebida pela
dedicado ao entendimento da VG Multimidia, empresa de produção
ferramenta Varnish-Cache e seus audiovisual da Noruega, responsável
recursos. No capítulo 3 será feito a pelo tabloide Verdens Gang. Com o
apresentação da metodologia, surgimento da demanda, a empresa,
incluindo uma apresentação da em conjunto com o Grupo de Usuários
aplicação de ensaio e os métodos Unix da Noruega e a Linpro,
utilizados para aferição. O capítulo 4 financiaram o desenvolvimento de uma
abordará a implementação da ferramenta de proxy reverso para suprir
ferramenta no ambiente de testes. O a necessidade do encontrada na
capítulo 5 será dedicado à época.
demonstração dos resultados,
Todo o desenvolvimento foi
enquanto que o capítulo 6 apresentará
chefiado pelo desenvolvedor
as conclusões alcançadas com o
dinamarquês Poul-Henning Kamp em
desenvolvimento deste artigo.
conjunto com Dag-Erling Smograv,
2. Varnish-Cache ambos membros ativos da comunidade
mantenedora do FreeBSD.
2.1 A história do Varnish-Cache

O Varnish-Cache teve como

ponto de partida a falta de uma solução

3
 Todo o esforço e conhecimento
aqui apresentado resultou na primeira
versão pública do Varnish-Cache,
disponibilizado ao público em 2006
Figura 3: Arquitetura do Varnish-Cache
com a licença BSD.
2.2.2 VCL
2.2 Aspectos Técnicos
As instruções dos arquivos de
O Varnish-Cache é um proxy-
configuração do Varnish são escritas
reverso, também conhecido como
usando uma linguagem própria,
acelerador HTTP, desenvolvido desde
chamada VCL.
o início tendo em mente esta função, ou
seja, ele busca aproveitar ao máximo O VCL trabalha com “ganchos”
os recursos do kernel do sistema- pré-determinados, que possuem
operacional com o intuito de funcionamento semelhante à
desempenhar da melhor forma possível sobrescrita de métodos na
sua função, sem o desperdício de programação orientada a objetos.
recursos. Durante o recebimento e o tratamento
da requisição, o Varnish dispara
2.2.1 Arquitetura
chamadas para estes ganchos, e
Todo o cache é armazenado em executa aquilo que foi escrito pelo
memória virtual, deixando a cargo do administrador.
sistema-operacional decidir o que será
Além de possuir esta estrutura
armazenado na memória RAM (que
familiar para diversos programadores,
apresenta alta velocidade / menor
o Varnish interpreta códigos em C,
capacidade) e o que será armazenado
abrindo assim um leque maior de
no disco-rígido (que apresenta baixa
possibilidades, ao permitir que exista a
velocidade / maior capacidade). Esta
interação do arquivo de configuração
arquitetura evita que a aplicação entre
com recursos externos.
em conflito com o sistema-operacional
ao tentar recuperar alguma informação O Varnish comporta diversos

que o primeiro necessita, mas o arquivos de configuração, que podem

segundo considera como informação ser carregados em tempo de execução,

não útil para aquele momento. evitando assim que seja necessário
reiniciar o serviço, além de permitir

4
chamadas a configurações diferentes 2.3 Simplificando o Entendimento
de acordo com a necessidade do
2.3.1 Funcionamento de uma
servidor.
estrutura “Cacheada”
2.2.3 Edge Side Includes (ESI) No diagrama abaixo (Figura 4)

O ESI (Edge Side Includes) é é possível conferir o funcionamento

uma linguagem de marcação XML básico de uma estrutura que funciona

criada para incluir e prover conteúdo em conjunto com o Varnish-Cache:

dinâmico dentro de páginas estáticas.

O Varnish faz uso apenas de

uma porção responsável pelo
gerenciamento da política de cache,
que é dada através da tag
<esi:include>.

Com a implementação Figura 4: Funcionamento do Varnish-Cache

efetuada, é possível, por exemplo,
Todas as requisições recebidas
determinar tempos de vida diferentes
pelo servidor são tratadas pela sub-
para cada parte de uma página. Sendo
rotina vcl_recv. Ela que é responsável
um recurso muito interessante para
por verificar se a requisição busca um
portais que apresentam seções com
objeto “cacheável” ou se é uma
atualizações de notícias, que
requisição que deve ser propagada
demandam um tempo de vida mais
diretamente para o servidor de
curto dentro de páginas que contém
conteúdo (Caminho vermelho).
uma listagem de artigos, que por sua
vez não demandam uma atualização Caso o objeto seja “cacheável”,
constante. é feito uma busca entre os objetos
armazenados em cache. Caso seja
Apesar de ser uma solução
encontrado, é disparado a sub-rotina
interessante para implementação em
vcl_hit, que por sua vez encaminha o
portais, ele fica restrito apenas à
objeto para a sub-rotina vcl_deliver,
servidores que o suportam, limitando
que é responsável por devolver a
as opções caso o projeto necessite de
resposta da requisição. Mas caso o
migração para outro servidor.
objeto não seja encontrado em cache,

5
é disparado a sub-rotina vcl_miss, que Sub-Rotina Função

propaga a requisição original para o vcl_init Chamado na inicialização do

VCL, antes de qualquer
servidor de conteúdo.
processamento.
Toda vez que o servidor de vcl_recv Chamado após o recebimento

conteúdo termina de processar a completo da requisição.

Decide o que será feito com a
requisição propagada pelo Varnish, é
requisição.
chamada a sub-rotina vcl_fetch, que é vcl_pass Chamado quando não se
responsável por determinar se o objeto deseja consultar o cache.
processado deverá ser armazenado vcl_hit Chamado quando um objeto é

em cache para depois ser enviado para encontrado no cache.

vcl_miss Chamado quando um objeto
o vcl_deliver ou se deve ser
não é encontrado no cache.
encaminhado diretamente para a
Pode propagar a requisição
resposta sem armazenar em cache. para o servidor de conteúdo.
vcl_fetch Chamado ao final do
2.3.2 As sub-rotinas
processamento do objeto pelo
servidor de conteúdo.
O Varnish trabalha com sub-
Determina se o resultado será
rotinas para agrupamento para melhor
armazenado em cache ou se
legibilidade ou reutilização de código. será encaminhado para
resposta.
Existem algumas sub-rotinas
vcl_deliver Chamado antes da entrega do
especiais que são chamadas no
objeto ao cliente.
decorrer do fluxo de trabalho do vcl_error Chamado quando é
Varnish. Estas inspecionam e encontrado um erro. Pode
modificam os cabeçalhos e outros reiniciar o processo ou
entregar o erro ao cliente.
aspectos das requisições HTTP, e em
Tabela 2: Sub-rotinas do VCL.
certos casos gerenciam a forma com
que tais requisições serão manipuladas
pelo servidor.

Algumas das principais sub-

rotinas chamadas pelo Varnish estão
relacionadas na Tabela 2.

6
2.4 Casos de Sucesso Implementado nos 14 países
em que atua com o suporte da Varnish-
2.4.1 Mercado Livre
Software em conjunto com a
Com um mercado de mais de consultoria da RedPill Linpro, o Varnish
550 milhões de pessoas e uma região permitiu a redução de custos com
com o maior índice de penetração da infraestrutura e um aumento de
internet, o MercadoLibre (Argentina) é disponibilidade, não encontrado em
o maior site de compras e vendas da outras soluções antes testadas.
américa latina. Atualmente é líder do
2.4.2 Facebook
segmento em 14 países, como
Argentina, Brasil, Chile, Colômbia, Fundado em 2004, a missão do

Equador, México e Venezuela. É um Facebook é entregar o poder do

comércio eletrônico comparável ao compartilhamento a seus usuários,

eBay. (MercadoLibre Case Study, tornando o mundo mais aberto e

VARNISH-SOFTWARE. Disponível em conectado. Qualquer um pode

http://tkme.in/to/Mjc). ingressar e interagir com pessoas que

conhece em um ambiente confiável.
Alguns fatos sobre o
Facebook é uma empresa privada, com
MercadoLivre (Disponível em
cede em Palo Alto, Califórnia (EUA).
http://tkme.in/to/Mjg):
(Facebook Case Study, VARNISH-
 MercadoLivre é o 11.º site de e- SOFTWARE. Disponível em:
commerce mais acessado do http://tkme.in/to/Mjk).
mundo e o 1.º na América
Alguns fatos sobre o Facebook
Latina, segundo dados da
(Disponível em: http://tkme.in/to/MzA):
comScore Networks.
 MercadoLivre é a fonte de renda  1 bilhão de pessoas, em 213

para mais de 134 mil pessoas na países (inclusive Vaticano).

América Latina. Ou seja, gera  2.7 bilhões de “Curtir” por dia.

trabalho e renda (Pesquisa  Disponível em 70 idiomas.

Nielsen 2012). “O Facebook utiliza o Varnish
 Média de 1000 buscas/segundo para servir bilhões de requisições todos
no site e 2 compras os dias, para usuários de todo o
concretizadas por segundo no mundo. Nós gostamos de sua
site.

7
arquitetura simples, desenvolvida para Não existem números precisos
sistemas operacionais modernos de referentes a economia no número de
forma a não consumir muito servidores, porém foi constatado uma
processamento enquanto está redução considerável no consumo de
sobrecarregado. Varnish é o nosso processamento dos servidores, já que
cache HTTP preferido e nós utilizamos apesar do número elevado de
ele massivamente, desde quando você requisições que o portal possui (32 mil
carrega uma foto ou seus amigos no acessos por minuto).
Facebook, há grande chance de ter o
2.5 Disponibilidade
envolvimento do Varnish.” (David
Recordon - Facebook) Por ser uma solução
independente do servidor web, o
2.4.3 Globo.com
Varnish permite a execução de rotinas
A Globo.com é um braço online específicas em caso de falha no
das organizações Globo, que atua em servidor.
diversos segmentos da comunicação.
Existe a possibilidade de
Seu canal de televisão é o maior da
reiniciar o processo de requisição após
América Latina e o terceiro maior do
uma quantidade de tempo específica,
mundo, perdendo apenas para as
assim como há a possibilidade de
redes CBS e ABC.
buscar pelo conteúdo em cache e
A área de TI investe o possível devolvê-lo ao cliente, evitando assim a
em soluções open-source, por isso em exibição de um erro. Este exibido
seu pátio o Linux é o sistema- apenas em último caso, quando
operacional primário, sendo possível nenhuma das rotinas anteriores obtém
encontrar com facilidade soluções sucesso.
populares, como MySQL, Apache
HTTPD e Apache TomCat.

A introdução do Varnish-Cache
na estrutura da Globo.com deu-se por
meados de 2008, quando decidiram
Figura 5: Sub-rotina para tratamento de erro interno.
substituir a antiga solução baseada no
Netcaches (da empresa NetApp, hoje
pertencente à Blue Coat Systems).

8
3. Metodologia Tendo isso em vista, foi
utilizado um notebook relativamente
Será adotado neste trabalho o
recente, ligado à tomada e com o
tempo de resposta, em milissegundos,
gerenciamento de energia configurado
como medida de comparação entre as
para fornecer o máximo de
duas soluções que serão
desempenho, com as seguintes
implementadas.
características:
O método utilizado neste
 Processador Intel Core i5-
trabalho visa simular um ambiente real,
2410M (2.30Ghz / TurboBoost:
onde um uma aplicação web será
2.90Ghz)
servido pelo servidor Apache a uma
 Memória RAM de 8GB
série de requisições.
 Disco Rígido SATA-2 de 500Gb
Para evitar qualquer tipo de
interferência externa, os experimentos
serão realizados em uma mesma 3.1.2 Servidor Apache / Apache
máquina física, com a utilização de + Varnish-Cache
máquinas virtuais idênticas entre si e
Para oferecer recursos
uma terceira máquina virtual atuando
idênticos, foi criado uma máquina
como cliente.
virtual com as seguintes
As ligações entre as máquinas características:
serão efetuadas via interface de rede
 Limitação à utilização de 1
emulada pelo software VirtualBox, da
núcleo do processador
Oracle.
 Memória RAM limitada à 4GB
3.1 Hardware  Disco Rígido de 4GB

3.1.1 Hardware Hospedeiro  Interface de Rede Intel Pro/1000

MT (Acesso à internet)
Com a decisão de utilizar
 Interface de Rede Intel Pro/1000
máquinas virtuais para a condução dos
MT (Acesso SSH)
experimentos, foi definido que a
máquina hospedeira oferecer recursos
suficientes para que não oferecesse
limitações aos servidores instalados.

9
3.2 Software De fácil utilização, o ab permite
a passagem de parâmetros
3.2.1 Sistema Operacional
personalizados, sendo eles:
Por tratar-se de um P Utilidade
equipamento de uso diário para tarefas Credencial básica de autenticação. Sintaxe –
-A
usuário:senha
de diversas áreas, o sistema
Tamanho do buffer (em bytes) do
operacional presente do hardware -b
envio/recebimento TCP
hospedeiro é o Microsoft Windows, em -c Quantidade de requisições simultâneas.

sua versão 8 para plataforma 64 bits. Adiciona a criação de Cookie ao cabeçalho

-C
da requisição. Sintaxe nome-do-cookie=valor
Nas máquinas virtuais em que Não exibe a mensagem de porcentagem de
-d
os testes foram conduzidos, o sistema serviços efetuados.
Escreve um arquivo CSV separado por
operacional adotado foi o Debian
virgulas, contendo a porcentagem de
-e
GNU/Linux 6.0.5 Squeeze com o kernel requisições servidas e o tempo da requisição

em sua versão 2.6.32-5-amd64. (em ms).

-f Especificar protocolo SSL/TLS.
Ainda com o intuito de reduzir Escreve um arquivo TSV, separado por
-g
interferências, as instalações dos tabulação, semelhante ao parâmetro –e
-h Exibir informações de uso.
sistemas operacionais foram
Adiciona informações extras ao cabeçalho da
conduzidas de forma a contemplar a -H
requisição.
estrutura estritamente necessária para -i Efetua requisições HEAD ao invés de GET

o funcionamento do servidor web, ou Habilita o KeepAlive, permitindo múltimas

-k
requisições na mesma sessão HTTP.
seja, foi instalado o sistema
-n Número de requisições a serem efetuadas.
operacional sem qualquer pacote extra, Arquivo contendo informações para o POST.
-p
como ambiente gráfico ou utilitários. Necessita do parâmetro –T
Credencial básica de autenticação para um
-P
3.2.2 Ferramenta para Medição proxy.
de Performance -q Oculta o contador em processos com mais de
150 requisições.
A ferramenta para aferir a performance
-r Não termina a sessão, mesmo com o
dos servidores neste estudo é o recebimento de erros.

utilitário ab. Disponibilizado em -s Utiliza HTTPS

conjunto com a instalação do servidor -S Não exibe os valores da mediana e do desvio

Apache, este utilitário permite realizar o
benchmark do servidor através de
requisições via protocolo HTTP.
padrão, nem as mensagens de erro quando
os valores estão acima do normal.
-t Tempo máximo de execução do teste. (Em
segundos)

10
-T O parâmetro Content-type da requisição em para o servidor apache, o Varnishhist
caso de POST/PUT.
utiliza “|” para representar requisições
-u Arquivo contendo informações para o PUT.
Necessita do parâmetro –T atendidas pelo cache, enquanto as
-v Nível de verbosidade requisições propagadas ao servidor
-V Mostra a versão e encerra. são representadas pelo “#”.
-w Exibe os resultados do teste em uma tabela
HTML em 2 colunas. 3.2.4 Softwares utilizados
-x String com os atributos da tag <table>.

-X Especifica a utilização de um servidor Proxy 3.2.4.1 Virtualização

para as requisições.
-y String com atributos da tag <tr>. Para a virtualização dos
-z String com atributos da tag <td> sistemas operacionais foi utilizado o
Tabela 3: Parâmetros do utilitário Apache Bench.
VirtualBox da Oracle, em sua versão
3.2.3 Varnishhist 4.1.22.

Para analisar o comportamento A escolha deve-se ao fato de

do cache, será utilizado a ferramenta que o software é oferecido de forma
Varnishhist, presente na instalação do gratuita através dos termos da GNU
Varnish-Cache. General Public License (GPL) 2, além
de ser Open Source.
Esta ferramenta permite
acompanhar todas as requisições 3.2.4.2 Suíte dos Servidores
recebidas, identificando quais foram
Como servidor HTTP, a escolha
atendidas pelo cache e quais
recaiu-se sobre o Apache. Servidor
necessitaram de consulta ao servidor
bastante popular e igualmente Open-
Apache.
Soure. A versão utilizada no ensaio é a
O histograma gerado pelo 2.2.16 disponível através do apt-get.
varnishhist exibe em seu eixo “x” uma
Por tratar-se de uma aplicação
escala logarítmica, com o tempo
dinâmica, foi utilizado o servidor de
decorrido entre o início e o fim da
banco-de-dados MySQL, em sua
requisição, sendo que 1e0 equivale a 1
versão 5.1 e o PHP em sua versão
segundo, enquanto que 1e-4 equivale a
5.3.3. Ambos também disponíveis
0,0001 segundos ou 1 microssegundo.
através do apt-get.
Para diferenciar as requisições
No caso do servidor
atendidas pelo cache das propagadas
responsável pelo ensaio com o

11
acelerador HTTP, foi instalado o o Varnish-Cache foi necessário a
Varnish-Cache, em sua versão 3.0, configuração da porta de escuta,
disponibilizada através do repositório permitindo assim que o Varnish fosse
do próprio desenvolvedor. consultado durante uma requisição. O
arquivo responsável por esta
4. Ensaio
configuração é o ports.conf, também
Com todos os recursos descritos e disponível em /etc/apache2 na linha
implementados conforme suas Listen.
respectivas documentações, esta
seção visa esclarecer as modificações
realizadas para que o sistema de cache
Figura 7: Configuração da porta a ser escutada pelo
reverso pudesse ser implementado. Apache.

4.1 Configurando o Apache 4.2 Configurando o Varnish

Com a instalação do servidor Com a instalação padrão

realizado em seu diretório padrão, a
alteração necessária em ambos os
casos é o diretório padrão do servidor,
onde ele buscará o conteúdo a ser
servido. A alteração ocorre dentro do
arquivo sites-available, disponível no
diretório /etc/apache2
DocumentRoot.
seguindo a documentação, o Varnish
necessitou de uma pequena
modificação no arquivo default.vcl,
disponível em /etc/varnish.
Tal modificação visa criar um
novo backend, ou seja, o recurso que o
na linha Varnish buscará caso não encontre o
objeto requisitado em seu cache.

Em conjunto com esta

modificação foi implementado uma
sobrescrita de forma a refinar a atuação
do Varnish-Cache, evitando com que
ele seja devolvido uma página de erro
caso o servidor de conteúdo ou o
Figura 6: Configuração da pasta que será servida pelo servidor de banco-de-dados não esteja
Apache.
disponível ou devolva um erro para a
Já no servidor em que o requisição.
Apache foi instalado em conjunto com

12
 compões cada cenário do ensaio e seu
respectivo tamanho.

Página Principal
Arquivo Tamanho
index 901 B
style.full.css 708 B
jquery.js 33,20 KB
init.js 1,17 KB
base.css 913 B
logo_g.png 9,67 KB
ico_mywork.jpg 6,87 KB
ico_info.jpg 4,28 KB
ico_blog.jpg 4,89 KB
ico_contact.jpg 4,67 KB
Total 67,2 KB
Figura 8: Arquivo default.vcl Tabela 4: Arquivos que compõem a página principal da
aplicação de ensaio.
4.3 Aplicação de Ensaio
Página Interna
Arquivo Tamanho
Como forma de simular uma meus-trabalhos 1,72KB
carga real para o sistema, foi utilizado init.js 369 B
style.css 966 B
uma aplicação desenvolvida com o
jquery.js 33,20 KB
auxílio do Zend-Framework em sua base.css 913 B
ico_blog.jpg 4,89 KB
versão 1.11.
ico_info.jpg 4,28 KB
wp.png 2,28 KB
Com o intuito de disponibilizar
ico_mywork.jpg 6,87 KB
cenários distintos, a aplicação ico_contact.jpg 4,67 KB
tw.png 1,52 KB
apresenta dois tipos de conteúdo:
logo_p.png 13,95 KB
Total 75,57 KB
 Página inicial – Conteúdo
Tabela 5: Arquivos que compões a página interna da
estático, sem consulta a fontes aplicação de ensaio.

externas.

Páginas internas – Conteúdo central

estático, com barra lateral dinâmica,
alimentado via rss (Blog Wordpress) e
consulta à API Twitter.

As tabelas a seguir (Tabelas 4

e 5) sumarizam os arquivos que

13
4.4 Sistemática Bateria 1
Requisições Totais Requisições Simultâneas

De forma a obter um resultado 1000 100

válido e com números próximos da Bateria 2

10000 100
realidade, serão estabelecidos padrões
Bateria 3
de teste para a condução do
100000 100
experimento. Tabela 6: Esquematização dos testes

O primeiro padrão rege que 5. Ensaio e Resultados

todos os experimentos deverão ocorrer
em condições iguais de sistema, ou
seja, ambos os servidores deverão
estar em um estado inicial comum.
Dado a impossibilidade de garantir o
estado de cada sistema,
experimentos serão realizados após
uma reinicialização da máquina virtual,
buscando um estado semelhante para
os dois servidores.
5.1 Ensaio com 1000 requisições
Conforme descrito
anteriormente na esquematização dos
testes, o primeiro ensaio é baseado
os numa fila de 1000 requisições, sendo
que este ensaio foi dividido de forma a
aferir o desempenho nas páginas
estática e dinâmica da aplicação de
ensaio.

O segundo padrão rege que

para se obter um resultado final,
deverão ser realizados cinco ensaios,
sendo o resultado final obtido através
de uma média aritmética dos
resultados obtidos em cada ensaio
individual.
Figura 9: Página Estática @ 1000 requisições
O terceiro padrão rege que
para se obter números absolutos, serão No teste inicial de 1000
efetuados ensaios com número de requisições em uma página estática foi
requisição variados conforme possível verificar que o tempo de
demonstrado na tabela 6. resposta do servidor Apache foi
deteriorando-se com o decorrer do
teste, tendo como resultado final um

14
tempo médio de resposta na casa dos buscamos agora a diferença de
4800ms (milissegundos). desempenho para uma aplicação com
maior fluxo de dados, para isso o
Em condições iguais de
ensaio foi realizado com uma fila de
equipamento e estado do sistema-
10000 requisições.
operacional, o servidor que funcionava
em conjunto com o Varnish-Cache
mostrou respostas mais estáveis,
fechando o teste com um tempo médio
de resposta na casa dos 3ms.

Figura 11: Página Estática @ 10000 requisições.

Com o maior número de

requisições para atender, é possível
verificar que o tempo médio de
resposta fica estável num intervalo
Figura 10: Página Dinâmica @ 1000 requisições
considerável de tempo, variando entre
Dentro do teste de carga com
4000ms e 6000ms, mas ao levar em
conteúdo dinâmico, o servidor Apache
consideração o ensaio completo, o
mostrou o mesmo comportamento que
tempo médio de resposta do Apache é
no teste anterior, elevando o tempo de
de 5055ms.
resposta no decorrer do teste. Tempo
médio de resposta: 20193ms. Repetindo mais uma vez a
estabilidade, o Varnish atingiu o tempo
Enquanto isso o Varnish
médio de resposta de 73ms.
apresentou o mesmo desempenho
estável que no ensaio anterior, mas
elevando o tempo médio de resposta
para 76ms.

5.2 Ensaio com 10000 requisições

Com os resultados de um
ensaio de carga leve em mãos,
Figura 12: Página Dinâmica @ 10000 requisições

15
 Observando o gráfico anterior é
possível verificar que apesar
elevação dos tempos de resposta, a
forma com que o Apache atende
continua semelhante. O tempo médio
alcançado pelo Apache foi
20757ms, contra 80ms conseguido
pelo Varnish.
5.3 Ensaio com 100000 requisições
A fim de exigir o máximo das
soluções testadas neste artigo, foi
estabelecido um teste envolvendo
100.000 requisições (cem mil).
Figura 13: Página Estática @ 100000 requisições
Devido ao elevado número de
resultados obtidos, o resultado deste
experimento foi demonstrado através
do gráfico de barras.
Para o ensaio com a página
estática, o Apache obteve um tempo
médio de resposta de 4820ms contra
75ms do Varnish-Cache,
demonstrando que o aumento de
requisições não fez com que o tempo
de resposta se deteriorasse com o
decorrer do experimento, apresentando
da tempos semelhantes aos ensaios
anteriores.
de
Figura 14: Página Dinâmica @ 100000 requisições
Neste último cenário, o Apache
necessitou em média de 20913ms para
atender cada requisição, ou um total de
5 horas para atender toda a fila que
compunha o experimento. Enquanto
isso o Varnish necessitou em média de
86ms para responder cada requisição,
ou um total de 1 minuto para completar
a fila de requisições.
5.4 Ensaios extremos
Para esclarecer a diferença que o
Varnish-Cache pode proporcionar a
uma estrutura de servidores, foram
realizados testes extras, contemplando
a mesma esquemática que os testes
anteriores, mas realizando 1000
requisições simultâneas. Em virtude da
limitação de hardware imposta para
este ensaio, o Apache não concluiu
todos os testes. Os resultados obtidos
podem ser verificados na tabela abaixo:
16
 Apache devolver objetos armazenados no
Estático cache, o Varnish permitiu que o
Req. Tempo
servidor atendesse um maior número
1000 Timeout – 250 requisições completadas
10000 Timeout – 304 requisições completadas de requisições num menor espaço de
100000 Timeout – 270 requisições completadas
tempo, sem que para isso fosse
Dinâmico
necessário aumentar os recursos
1000 Timeout – 110 requisições completadas
10000 Timeout – 106 requisições completadas disponíveis no sistema ou mesmo
100000 Timeout – 98 requisições completadas
esgotar os recursos e paralisar os
Tabela 7: Tempos do Apache
testes.
Varnish
Estático Apesar dos resultados
Req. Tempo positivos alcançados aqui, um passo
1000 151ms / requisição
natural a ser seguido nesta pesquisa é
10000 328ms / requisição
100000 Timeout – 27000 requisições completadas a implementação do Varnish-Cache em
Dinâmico um ambiente de produção real,
1000 153ms / requisição
efetuando otimizações pontuais
10000 350ms / requisição
100000 Timeout – 22603 requisições completadas através do VCL de forma a atender a
Tabela 8: Tempos do Varnish
requisitos específicos de diversas
6. Considerações Finais áreas do sistema.

Com base no tempo Deve-se elaborar também uma

necessário para implementação e nos
resultados obtidos ao longo deste
trabalho, pode-se concluir
Varnish-Cache apresenta resultados
sólidos, que podem comprovar sua
eficácia em um ambiente que necessite
de disponibilidade de recursos mas
com limitação de hardware
atender às necessidades de visitação.
Mesmo com as limitações de
hardware impostas para a realização
dos experimentos, a utilização de proxy
reverso mostrou-se bastante eficaz. Ao
abordagem referente à utilização do
Varnish-Cache em conjunto com outros
que o recursos, como banco-de-dados não
relacional e servidores web compactos.
Visando assim gerar novos objetos de
forma ágil, armazenando-os em cache
de forma a criar um ambiente de
para aplicação ágil e robusto, sem que para
isso seja necessário altos
investimentos.

17
7. Referências BRITO, SAULO, Varnish Cache – O que é e
como implementá-lo
VARNISH SOFTWARE, Varnish Cache
Disponível em <http://tkme.in/to/MzQ>. Acesso
Documentation.
em 27 jul 2012
Disponível em: <http://tkme.in/to/MjA>. Acesso
em 17 mai 2012 WALLEN, JACK, DIY: Speed up your Apache
server width Varnish Cache.
AGUIAR, ALEXANDRE S., Varnish: Uma
Disponível em <http://tkme.in/to/MzU>. Acesso
camada de velocidade.
em 27 jul 2012
Disponível em: <http://tkme.in/to/MjE>. Acesso
em 18 mai 2012 CETIC.BR. TIC Domicílios e Usuários 2011.
Disponível em <http://tkme.in/to/MzY>. Acesso
KAMPP, POUL-HENNING, Varnish – the
em 10 ago 2012
HTTP accelerator (2006). Vìdeo MPEG
(240MB – 104min). Disponível em: O’REILLY, TIM, What Is Web 2.0
<http://tkme.in/to/MjQ> Disponível em <http://tkme.in/to/Mzc>. Acesso
em 14 abr 2012
SOUDERS, STEVE, High Performance Web
Sites – 14 rules for faster-loading pages. APACHE, ab – Apache HTTP server
Disponível em: <http://tkme.in/to/MjU>. Acesso benchmarking tool.
em 14 jul 2012 Disponível em: <http://tkme.in/to/Mzk>. Acesso
em 20 out 2012
NOTTINGHAM, MARK, ESI Language
Specification 1.0.
Disponível em <http://tkme.in/to/MjM>. Acesso
em 17 jul 2012

FUG-BR, Varnish-Cache – Servidor de Proxy

Reverso com Cacheamento.
Disponível em <http://tkme.in/to/MjI>. Acesso
em 17 jul 2012

VARNISH SOFTWARE, Globo Case Study.

Disponível em <http://tkme.in/to/MzE>. Acesso
em 20 set 2012

VARNISH SOFTWARE, MercadoLibre Case

Study.
Disponível em <http://tkme.in/to/MzI>. Acesso
em 20 set 2012

VARNISH SOFTWARE, About Facebook

Disponível em <http://tkme.in/to/MzM>. Acesso
em 20 set 2012

18