Reverse Proxy Performance – Varnish vs. Squid (Part 2)
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
Related posts:
- Reverse Proxy Performance – Varnish vs. Squid (Part 1) Typical web applications require dozens of SQL queries to generate...
- Varnish Cache – Servidor de Proxy Reverso com Cacheamento O Squid é sem dúvida um dos mais poderosos e...
Posts relacionados trazidos a você pelo Yet Another Related Posts Plugin.
