We’ve been using Varnish cache for some time, and I’ve been massively impressed by both its performance and flexibility.  As part of a solution to help scale websites it’s unbeatable, especially with its support for ESI.

Anyway, we wanted to integrate monitoring of Varnish into the existing Cacti setup we have, and so I wrote a little plugin to do this.  It’s loosely based on the code posted here but it’s more ‘inspired by’ rather than based upon.

It produces just one graph (above), which shows the number of requests/second, hits/second and misses/second.

Installation is pretty straightforward:

• Make the Varnish management daemon available to your Cacti machine (Make sure you lock down appropriately with iptables or similar, because there is no authentication for this interface)
• Copy get_varnish_stats.py to your cacti scripts directory (/usr/share/cacti/site/scripts in Debian/Ubuntu)
• Import the XML template via the Cacti interface

You can download the plugin here.

No tags

I’ve been preaching the standard ‘development’, ’staging’ ‘production’ method of testing and deploying software for pretty much as long as I can remember.  This made me all the more interested to read this post telling how IMVU, an ‘avatar based chat site’ go programatically straight from commit to deploy.

 The high level of our process is dead simple: Continuously integrate (commit early and often). On commit automatically run all tests. If the tests pass deploy to the cluster. If the deploy succeeds, repeat.

Whether this approach would work for you really rather depends on the type of environment you work in. What would concern me most is how one could possibly deal with intermittent problems which one was unable to consistently reproduce.  The continuous deployment solution, I suppose, would be to write a number of tests which reproduce the circumstances around the failure.

It’s certainly an interesting idea though, and one that is clearly working for IMVU.

Code, deployment, testing