Evaluating Varnish and charting cache stats using Graphite

Published December 9, 10:29 p.m. GMT


Up until recently I had always used squid cache to reverse proxy my employers website. I'm a big fan of Squid and of reverse proxies in general because they are easy to scale out and they usually deliver much better response times for less buck than a standalone web server might. Squid is pretty good at what it does, it support a ton of protocols, has a good track record as far as security and stability are concerned and it is used by a lot of really of really big sites including Wikipedia and Flickr. But for the past couple of years I have also had my eye on Varnish cache, the new kid on the block, designed solely as a high performance reverse proxy. I think I actually first came across varnish on the Squid Users mailing list. Varnish promises some potential advantages over Squid in reverse proxy mode.

  1. Squid's emphasis from version 3.1 onwards seems to be content filtering. It has some cool new features such as ecap support but performance oriented users are advised to use the older 2.7. Varnish on the other hand seems to be focused on delivering a high performance reverse proxy and boasts some incredible statistics for numbers of requests served per second.
  2. Squid's memory/disk architecture was designed for a time when memory was expensive and it made sense to cache some stuff to disk, but memory is pretty cheap now and Varnish will allow me to make more efficient use of the higher memory densities in today's servers. Being able to use memory only, rather than memory and disk is advantageous for a caching system with a high level of requests per second because caching servers like Squid and Varnish are usually IO bound. With Squid I have found the general rule to be that I can only use up to 30% of total memory for my cache, with Varnish the recommended figure is 80%.
  3. Varnish's configuration language is really, really flexible.

Squid does have some advantages over Varnish, including, but not limited to it's built in SSL support and caching of 'cookied' content. But for my use case the main benefits of Varnish, namely performance and the flexibility of it's VCL configuration language far outway the disadvantages. 

So far my testing is in an advanced state and going well. Varnish out of the box is configured for high performance and if you are migrating from Squid to Varnish then it is important to be aware the Varnish does not always follow the HTTP standards regarding cacheable content as strictly as Squid does. An example of this is the way that Varnish 'out of the box' considers content with 404 status codes to be fair game for caching. The good news is that Varnish's VCL language gives you the control to change all of the defaults to your liking.

Part of my evaluation of Varnish involves comparing it to similarly configured Squid boxes under similar load. With Squid I had really nice graphs from http://wessels.squid-cache.org/squid-rrd/ that I could use to monitor the performance of my individual caches. Varnish has a nice command, 'varnishstat' that will spit out useful stats for a running instance but there does not currently seem to be any free, off the shelf stats graphing system available for Varnish 3+. So I wrote a little app called pyVarnish that uses Graphite to graph the output of Varnishstat from remotely running servers over ssh. I've put the code up on Github. I'll put some documentation on Pyvarnish and Graphite together for another blog post.

Graphite Sample

Filed under: graphite, http, python, pyvarnish, squid, varnish , categories HTTP , Python , Squid and Varnish

blog comments powered by Disqus
John Moylan's twitter page
John Moylan youtube favourites channel
John Moylan linkedin profile