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: 70.810 ]

Por: Perfil removido em 10/05/2010


Parte 2 - Testes de benchmark



Objetivo:

Wikipedia [13] apresenta o termo benchmark como "ato de executar um programa de computador, um conjunto de programas e operações, afim de avaliar a performance relativa a um objeto".

Nos testes executados neste trabalho, o objetivo também foi o de avaliar a performance do software Varnish, simulando da melhor forma possível o ambiente da Internet, e comparar sua performance com a do Squid e ao Zope/Plone sem cache.

Para realização deste teste foi feita a instalação, no servidor, de uma aplicação Zope-Plone, em seguida, esta foi preenchida com algumas notícias, assim como funcionam os sites na Internet. Feito isto, foi selecionado, como massa de dados, um conjunto de 232 links referentes a carga completa de 5 páginas do portal criado.

Ambiente de testes Zope / Plone
Para aferição dos testes, foi utilizado o software Siege simulando o acesso de 30 usuários simultaneamente às páginas Web. Cada teste durou 3 minutos e foi repetido uma vez, sendo ignorada a primeira execução, pois nesta execução o proxy ainda estava sem carga, fato que não aconteceria na Internet.

Descrição da infraestrutura:

Servidor:
  • Servidor Dell 2960
  • CPU 2x Intel Xeon E5410 Quad Core Processor @ 2.33GHz
  • Memória 8Gb
  • Linux Debian 5.2 Kernel 2.6.26-2-686-bigmem

Cliente:
  • Notebook HP Compaq 2710b
  • CPU Intel(R) Core(TM)2 Duo CPU T5470 @ 1.60GHz
  • memória 2Gb
  • Linux Ubuntu 8.04

Descrição do SO:
  • Squid 3.0
  • Varnish 2.0.4
  • Zope 2.9
  • Plone 2.5.5
  • Siege 2.6.9

Após a conclusão dos testes, os resultados encontrados foram os seguintes:

Zope-Plone

Transactions:             11679 hits 
Availability:             100.00 % 
Data transferred:         70.22 MB 
Response time:            0.46 secs 
Transaction rate:         65.10 trans/sec 
Throughput:               0.39 MB/sec 
Concurrency:              29.91 
Successful transactions:  11499 
Failed transactions:      0 
Longest transaction:      6.56 
Shortest transaction:     0.06 

Squid

Transactions:             66458 hits 
Availability:             100.00 % 
Data transferred:         393.89 MB 
Response time:            0.08 secs 
Transaction rate:         370.78 trans/sec 
Throughput:               2.20 MB/sec 
Concurrency:              29.75 
Successful transactions:  65350 
Failed transactions:      0 
Longest transaction:      3.58 
Shortest transaction:     0.00

Varnish

Transactions:             300821 hits 
Availability:             100.00 % 
Data transferred:         1787.26 MB 
Response time:            0.02 secs 
Transaction rate:         1676.35 trans/sec 
Throughput:               9.96 MB/sec 
Concurrency:              29.97 
Successful transactions:  295664 
Failed transactions:      0 
Longest transaction:      3.01 
Shortest transaction:     0.00 

O primeiro número ressaltado nos testes é o de transações atendidas por segundo. Enquanto o Squid representou um crescimento de 569% em relação ao sistema sem cache, o Varnish apresentou um crescimento de 2575%, tendo uma performance em número de transações atendidas de 452%.

Número de transações atendidas por segundo
Outro número que chama bastante a atenção é o tempo médio de resposta. Enquanto o Squid apresentou um número 575% menor em relação aos testes sem cache, o Varnish apresentou um número 2300% mais rápido tendo um ganho em relação ao Squid de 400%.

Tempo médio de resposta
Em abril deste ano, Li Cherife [14] publicou em seu Blog um teste de Benchmark envolvendo o Varnish 1.1.2, o Squid 2.6 e o Squid 3.0. Como infraestrutura, o Li conseguiu montar 3 servidores conforme descrição abaixo:

Um switch de 24 portas Gigabit D-Link 1024R.

Servidor Web:
  • OS: Linux 2.6.21.5-smp i686 (Slackware 12.0)
  • CPU: Intel(R) Xeon(TM) CPU 2.80GHz x 2
  • MEM: 1024M x 6
  • DISK: SEAGATE ST373405LC SCSI Disk
  • Ethernet controller: Intel 82546EB PRO/1000 MT Dual Port Server Adapter

Servidor de proxy:
  • OS: Linux 2.6.21.5-smp i686 (Slackware 12.0)
  • CPU: Intel(R) Xeon(TM) CPU 3.06GHz x 2
  • MEM: 1024M x 6
  • DISK: RAID 5
  • Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller

Cliente:
  • OS: Linux 2.4.31 i686 (Slackware 10.2)
  • CPU: Intel(R) Xeon(TM) CPU 2.80GHz x 2
  • MEM: 1024M x 6
  • Ethernet controller: Intel 82546EB Gigabit Ethernet Controller

Como massa de dados, Li utilizou um script em bash para criar 2 arquivos de 10mb, 1000 arquivos de 10kb e 10 arquivos de 1Mb.

Arquitetura de testes montada por Li Cherife
Para averiguação dos resultados, Li utilizou o software http_load, simulando 100 usuários acessando simultaneamente e fazendo ao todo 100.000 requisições à massa de dados de forma sequencial.

Os resultados obtidos foram:

Varnish
100000 fetches, 100 max parallel, 1.024e+09 bytes, in 14.7505 seconds
10240 mean bytes/connection
6779.43 fetches/sec, 6.94213e+07 bytes/sec
msecs/connect: 0.400918 mean, 11.452 max, 0.067 min
msecs/first-response: 14.0161 mean, 1779.32 max, 0.24 min
HTTP response codes:
code 200 - 100000 

Squid 2.6
100000 fetches, 100 max parallel, 1.024e+09 bytes, in 26.1771 seconds
10240 mean bytes/connection
3820.13 fetches/sec, 3.91181e+07 bytes/sec
msecs/connect: 0.497665 mean, 2990.79 max, 0.055 min
msecs/first-response: 21.0663 mean, 3018.84 max, 4.071 min
HTTP response codes:
code 200 - 100000 

Squid 3.0
100000 fetches, 100 max parallel, 9.85651e+08 bytes, in 102.375 seconds
9856.51 mean bytes/connection
976.8 fetches/sec, 9.62785e+06 bytes/sec
msecs/connect: 2.56114 mean, 91.428 max, 0.061 min
msecs/first-response: 27.8048 mean, 94.563 max, 1.288 min
3751 timeouts
3745 bad byte counts
HTTP response codes:
code 200 - 96255 

Nesse teste, a quantidade de transações atendidas por segundo do Varnish é superior ao número aferido utilizando o Squid 2.6 em 177%. Devido ao grande número de falhas por timeout encontrados, o tempo médio de requisições atendidas por segundo para o Squid 3.0 ficou muito comprometido.

Número de transações atendidas por segundo
Observando os testes feitos por Li [14] e comparado-se com os testes executados neste trabalho, foi observado que, embora em ambos os testes os resultados do Varnish se mostrem muito superiores aos encontrados com o proxy Squid, os números do teste executado neste trabalham apresentam diferenças muito superiores aos encontrados do Li.

De fato, o Squid, por padrão, não realiza cache de requisições com cookies, requisições de páginas com variáveis post ou get, enquanto o Varnish possibilita ajustes finos em suas configurações para permitir o cache ao máximo.

Página anterior     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

pam_mount e CiD - Gerenciamento centralizado dos mapeamentos de unidades de rede no Ubuntu

expr - Definição e uso do comando

Sistemas de arquivos - Conceitos básicos

Deface: A arte de desconfigurar sites

Configurando suporte Firebird no LAMP (xampp) em Lubuntu

Leitura recomendada

VivoZap do Moto Q no Ubuntu

Como configurar uma rádio virtual no Linux (Fedora Core 4)

Linux, uma experiência de uso

CoyoteLinux :: Compartilhando internet com um disquete

Compartilhando a internet com apenas uma placa de rede e um hub/switch

  
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




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts