In part one of this series I tested the raw throughput performance of Varnish and Squid.  My results are consistent with all the blogs and comments floating around the blogosphere – Varnish blows away Squid.

Unfortunately, the first series of tests were somewhat uninformative.  Since they only tested the raw performance of serving cached content from memory, it did not mimic a real world scenario of serving cached content as well as fetching content from the backend and caching it.

While we would hope for a primed, full cache, it is unlikely to happen and you will undoubtedly see a decent amount of backend requests from your caching proxy.

A better test of the two proxies would involve a large set of random URLs, but not too random because we want to simulate both cache hits and cache misses.  To accomplish this, I wrote a small PHP script that would take two parameters: total number of URLs to generate and the hostname for those URLs.

Generating a usable URL list

Generating the list is simple.  This script looks like this:

<?php
        ob_start();
        $total = $_GET['total'];
        $host = $_GET['host'];
        for ($i = 0; $i < $total; $i++) {
                // generate random numbers
                srand(time());
                $random = mt_rand(10, 40);
                $random2 =  mt_rand(1, 100);

                if (substr($random2,0,1) > 1) {
			$as="?as=$random2";
		} else {
			$as = "";
		}
                echo "http://$host/varnish/gen/$random$as\n";
                flush(); ob_flush();
        }
        echo "http://$host/varnish/gen/$random$as";
?>

All this does is create a long list of URLs.  I used PHPs output buffering mechanisms to flush the buffer which is necessary when creating large URL lists so that you don’t wait forever.  Maybe it could have been written better but I don’t care – that wasn’t the point of this test.

The URLs that are created are in the format of:

http://host/varnish/gen/50?as=100

http://host/varnish/gen/50

This URL is mapped to another PHP file that simply generates dummy data of the size specified in the URL.  In the above cases, the files would be 50Kb large.  The query parameter “as” is just a useless piece of information that is meant to tell the proxy to cache it.  If the “as” query parameter does not exist, the proxy will forward the request to the backend and not cache it.  Its a simple way to generate cacheable and non-cacheable URLs.

To generate the list and store it in a local file, I used this command:

curl http://192.168.165.101/varnish/makelist.php?total=10000&host=192.168.165.104:8080
	> urls-10k.txt

Verify the results of the script

For your own sanity, make sure that the script did in fact generate a list of URLs that suits your needs.

Count the amount of URLs generated:

cat urls-10k.txt | wc –l

(yes, I know it creates one extra URL … Its fine by me.)

Count the amount of cacheable URLs containing the “as” query parameter:

cat urls-10k.txt | grep as | wc –l

Count the amount of unique cacheable URLs:

cat urls-10k.txt | grep as | sort | uniq | wc –l

Running the tests

In part one I used ApacheBench to load the servers but for these tests, I used Siege and http_load which both allowed me to load URLs from a file.

I started with Varnish using the following commands:

curl http://192.168.165.101/varnish/makelist.php?total=100000&host=192.168.165.104:8080
	> urls-100k.txt

http_load -parallel 10 -fetches 100000 urls-100k.txt
http_load -parallel 25 -fetches 100000 urls-100k.txt
http_load -parallel 50 -fetches 100000 urls-100k.txt
http_load -parallel 100 -fetches 100000 urls-100k.txt
http_load -parallel 200 -fetches 100000 urls-100k.txt
http_load -parallel 400 -fetches 100000 urls-100k.txt

In between each http_load command, I restarted the Varnish service so that each test ran with an empty cache.  When I was done with the Varnish tests, I ran the same tests against Squid using the same commands above.

The results

The results of these tests represent the typical web application much better than the original tests did.

This first graph shows the average time for the proxy to accept a connection.  As concurrency goes up, it is expected that the time to connect would go up too.  Squid suffers more than Varnish does, but the difference is negligible.

The second graph is much more interesting.  As concurrency goes up, the Time-To-First-Byte for Squid goes up very sharply while Varnish holds its ground and remains very quick around 25ms.

This third graph shows another interesting behavior.  As concurrency goes up, Varnish begins to even itself out at just under 800 fetches per second while Squid peaks at around 1100 fetches per second with around 50 concurrent connects and then sharply drops off as concurrency goes up.

Conclusion

Squid versus Varnish is just another holy war that may never end.  The tests that I have performed have been very helpful for me and my team but your results may vary.  Of course, there are many more things to consider and I plan to write about some of the major differences between Squid and Varnish.

My results show that in raw cache hit performance, Varnish puts Squid to shame.  In real world scenarios I found that Squid can hold its own when dealing with small amounts of traffic, but it’s performance drops off very sharply as it begins to handle more connections. Varnish handles them without a sweat, as it was designed to do.

My next blog post will detail the differences between Varnish and Squid’s architecture, features, and the reasons I am pushing for Varnish in our environment.

Edit:

Some people are complaining in comments on Reddit and HackerNews that I have not provided any information about the hardware or operating system for my tests.  This information was posted in Part one of this post.

Fonte: http://deserialized.com

Typical web applications require dozens of SQL queries to generate a single page.  When your application is serving over 1,000,000 pages per day, you quickly realize that the performance bottleneck is your database.  The typical answer to slow database queries is “just use memcached!”  Memcached and other data caches can only take you so far.  This is where reverse proxies come in.  There are a handful of them out there, including Nginx, Perlbal, Squid and Varnish.  Which to use is up to you.

Deciding what is best for you

Assuming that you have taken a step back and really analyzed your problem first, the next step is to analyze the possible solutions.  For us, Varnish seems like the best option with Squid close behind.  To be fair, I’ve set up a test server with both Varnish and Squid running.  I’ll use ApacheBench to generate load and requests.

I’ve analyzed our pages to see what the typical page size is and recorded the average page sizes for 5 different page types.  They range from around 10KB to 35KB (gzipped).  For my test, I’ll be benchmarking with 10KB, 15KB, 20KB, 30KB, 40KB, and 50KB files to get a good range of different size requests.

To test under different load capacities, I’ll use ApacheBench to generate loads with different amounts of concurrent users ranging from 10 to 400.

The test

I’ll be using two identical machines on the same local class C network to eliminate (as much as possible) network latency.

The machines look something like this:

• Pentium 4 3GHz (8KB Level 1, 512KB Level 2)
• 2GB (4×512 DDR 400MHz)
• 120GB ATA Western Digital Caviar WD1200JB
• CentOS 5

(I don’t have more information than that.  Suffice to say that it is a few years old and not very powerful)

I am using Varnish 2.04 and Squid 2.6.STABLE21.  There are newer versions of Squid but i am using this version because the 3.x branch is missing features found in the 2.x branch and I have read several reports of 2.7 crashing, etc.

The command to run the load test looks something like this:

ab –c concurrent_users –n total_requests “url”

This will let you specify how many concurrent users to run and how many requests to make.  I have the proxy servers running on ServerA and I run the benchmark from ServerB.

The results

In general, Varnish seems to perform twice as well as Squid does.  In every test, Varnish serves nearly 2x more requests per second and has half the average response time.

Here are the graphs of the above data for easier visualization:

Something is wrong here

These are simply benchmarks and are not meant to represent real world scenarios for a few reasons.  Most importantly, this test takes place on a local network that goes through one router.  Running this test on a local network does not take into consideration the typical network latency you would find across the internet.

Secondly, this test only illustrates the raw speed of serving up cached content which isn’t a typical real world scenario.  To really test the overall performance of both of these, we need to simulate the three major steps of a reverse proxy:

1. Forwarding a request to a backend server
2. Physically caching it (memory or disk)
3. Serving the cached data

Testing any of these three steps is good, and shows the raw performance of that function but it doesn’t give us a general overview of the overall performance.

Next Steps

I need to come up with a way to generate load on the server such that it represents the typical flow of requests that we would normally see on a server.  I am running this on a test server, not against production data, so if anyone has an idea of how I can do this, please do let me know.  The results of this test will be Part 2 of this post.

Additionally, please let me know if you spot inefficiencies in my testing methodology. I don’t claim to be a load testing expert so any advice you can offer is appreciated.

Fonte: http://deserialized.com

O Squid é sem dúvida um dos mais poderosos e completos sistemas de caching proxy do mercado. Para nossa sorte, é livre e conhecido por funcionar muito bem no FreeBSD. O Squid é utilizado frequentemente como servidor de procuração e cacheamento de dados servindo uma rede ou algumas estações, para acesso à grande rede.  Mas o Squid também é projetado para atuar como Reverse Proxy com cacheamento. Um servidor de procuração reverso funciona de forma similar a um servidor de procuração convencional, mas ao invés de atender uma rede pré-conhecida ou uma estação, atende a toda Internet, mas seu target de procuração e cacheamento é normalmente apenas um (ou alguns) servidor(es) Web. Por isso é denominado proxy reverso, pois faz a procuração para acesso e cache de servidores Web pré-conhecidos. Por exemplo, imagine que você entre em um site na Web, como http://www.freebsd.org ou http://www.fug.com.br. Normalmente espera-se que quem atenda sua requisição HTTP/1.0 ou superior seja o servidor Web desses sites. Se um proxy reverso existir, sua requisição será atendida por este proxy, e não pelo servidor Web. O objetivo é aliviar a carga do servidor Web e poder oferecer à diversos clientes acessando o site ao mesmo tempo o mesmo conteúdo, resultado do processamento único realizado pelo Web server, ao invés de exigir que o próprio servidor http cuide de processar esse site.

À primeira vista o uso de um proxy reverso parece não ter grandes vantagens, especialmente porque o consumo de banda, observado por alguns como a grande vantagem de uso de um servidor de procuração, não existirá, já que, sendo transmitido do servidor Web ou do proxy, a demanda de largura de banda dos dados será a mesma. Correto, mas esse é o único ponto onde o proxy reverso não apresenta vantagens. Em grandes sites e principalmente em sites com conteúdo essencialmente dinâmico, o custo mais relevante não é banda, mas sim recursos computacionais e atendimento paralelo à requisições Web. Apesar de servidores como Apache serem extremamente robustos e atender seguramente a demanda de requisições paralelas, a questão de desempenho é afetada devido à necessidade de sites dinâmicos ter que ser processados sempre, toda vez, para cada requisição Web feita.

Tendo em vista esta grande demanda de recursos de processamento, o próprio Apache já tem seu módulo de proxy reverso, inclusive com algum suporte à cacheamento de objetos. E não é só. Linguagens popularmente usadas em ambiente livre como php tem versões de aceleradores de objetos. São sistemas livres e proprietários, todos com o mesmo objetivo: acelerar o processamento de conteúdo gerado dinâmicamente. Mas esses aceleradores não são de propósito geral. Por exemplo, não existe acelerador que funcione bem para PHP, Java e Perl ao mesmo tempo. Pior ainda se há um servidor com ASP no ambiente Web em questão. Nesses casos o proxy reverso é a solução mais indicada.

Mas os dias de hegemonia do Squid, atuando como proxy reverso e sendo unanimidade de opções para tal função, estão contados. Pelo menos é o que promete a VG Multimedia e o Grupo de Usuários Unix da Noruega. Segundo a VG Multimedia, empresa de produção áudio-visual da Noruega, o Squid atuando como Reverse Proxy se apresentou limitado demais em performance, por uma série de motivos incluindo não fazer uso apropriado de várias tecnologias disponíveis em sistemas computacionais modernos. O módulo de proxy reverso do Apache também não se mostrou satisfatório em ambiente de grande demanda. Essas averiguações já foram constatadas por grandes provedores de conteúdo dinâmico. O Yahoo! por exemplo usa uma solução de Proxy Reverso própria. No Brasil alguns dos maiores provedores de conteúdo usam o Netapp ou similar, de fabricantes como Sun Microsystems, IBM ou outras empresas.

Mas no mundo livre, a melhor opção até então era mesmo o Squid, atuando em um ambiente para o qual ele não foi originalmente projetado. Recentemente a VG Multimedia, grupo responsável pelo maior jornal publicado no país e o Grupo de Usuários Unix da Noruega e da empresa de Consultoria em Linux, Linpro, se uniram para financiar a criação de um novo projeto: o Varnish Cache. E os resultados já estão aí: em um benchmark recente comparando Varnish com Squid usando diskd(8) como proxy reverso, Varnish apresentou 600% mais performance que o Squid. O motivo, segundo seus desenvolvedores, é simples: código. Varnish utiliza racionalmente técnicas como Copy-On-Write e o uso do sendfile(2). Evita chamadas de sistema onde não é impossível deixar de usá-las, e introduz um novo algorítimo de cacheamento de objetos dinâmicos. Os detalhes internos das diferenças de codificação usadas podem ser acompanhados em um vídeo recente com palestra técnica sobre o Varnish Cache. Varnish tem ainda mais vantagens. Ele é capaz de cachear conteúdo considerado não-cacheável por outros sistemas. Incluíndo dados protegidos por senha.

O ambiente de desenvolvimento e uso em produção do Varnish Cache é FreeBSD, especificamente FreeBSD 6 -STABLE e 7 -CURRENT. O único Linux utilizado durante o desenvolvimento, para garantir compatibilidade com o kernel Linux é o Ubuntu Dapper. Isso porquê os desenvolvedores do Varnish são velhos conhecidos da comunidade FreeBSD. O desenvolvedor chefe é Poul-Henning Kamp e o líder do Projeto é Dag-Erling Smøgrav. Ambos commiters FreeBSD. A licença do Varnish é Licença BSD de dois cláusulas.

Se você ficou curioso e quer saber mais sobre o Varnish, vai gostar de saber que mesmo antes de ser oficialmente lançado, já estava disponível na Coleção de Ports do FreeBSD, em /usr/ports/www/varnish. Vai querer também assistir ao vídeo de apresentação técnica do Varnish , incluindo discussões sobre implementações internas e algorítimos escolhidos e criados para o Varnish, ou talvez ouvir a apresentação em mp3. Como é um novo esforço, a documentação do Varnish ainda é pouca, mas um bom começo pode ser observado aqui.

Apenas para não gerar confusão, é importante deixar claro que o Varnish não é feito para atuar como um proxy convencional, tão pouco para substituir o Squid ou qualquer outro proxy a não ser exclusivamente atuando na função de proxy reverso.

Fonte: http://www.fug.com.br/