Rui CarmoI started doing some housecleaning last weekend, and ended up playing around with a few new toys.
This server has been running Ubuntu for a good while (ever since I moved to Linode), and it’s gone through a couple of upgrades without any significant hitches. My current setup has a few interesting twists, so this time it was a bit harder.
First off, I use LXC containers to segregate a number of different environments - the host itself runs pretty much nothing (not even SSH, only iptables to NAT incoming traffic to containers), and the container layout is more or less as follows:
- The frontend container runs Varnish and a SPDY reverse proxy as isolated, unprivileged processes. Varnish performs RAM caching for all the virtual hosts this box supports and the SPDY daemon talks directly to it.
- Any requests that make it through the cache are proxied to another container that has the absolute minimum to run a specific app. In this site’s case, that’s basically Python, ImageMagick and the Dropbox CLI daemon.
- A number of other containers sit around ready to be fired up or shut down as required, ranging from a development version of the site to my Android playground, and including a dedicated RStudio instance, some git mirrors - even a Quake server1…
As a rule, third-party binaries get their own little bottle to rattle around in and some resource limits to try to make sure they don’t starve out the rest, and toys are segregated as well to make it easier to get rid of them once I’m through.
After all, the most neglected sysadmin skill is housekeeping, so it pays to be able to remove junk easily when necessary.
Ubuntu Peculiarities
All that is fine and good, but Ubuntu 12.04 tries to make things “easier”, for a given value of the same that entailed breaking my perfectly good container setup. Weird things happened like virtual interfaces being preserved but containers refusing to boot, having my defaults ignored for some reason, and old templates becoming unavailable.
Bottom line: it was actually faster to rebuild the containers from scratch and move the relevant files to fresh lodgings than sort out the whole thing. Contrasting this with a similar Debian setup that has survived a few updates (both in individual containers and the host) and, in the whole, I feel justified in wishing I’d set up Debian to begin with.
So that’s why the site was down during Sunday afternoon. In retrospect, given that it took me all of 15 minutes to rebuild two containers from scratch and move data across, I shouldn’t have bothered trying to get the old ones to run, but there you are - live and learn…
SPDYness
On to the main course, then.
I’ve been wanting to play with SPDY for a good while now - partly because I’d like to build a Python framework that handled SPDY natively (in line with the hundreds of little HTTP tweaks and optimizations I built into Yaki), and partly because I’m a staunch believer in improving wire protocols.
But there simply wasn’t anything around that I could deploy easily (largely due to the requirement for NPN support in OpenSSL, which is finally satisfied in recent updates), so when I came across spdylay’s shrpx (which implements portions of Draft 3, has a fairly small codebase and is actively maintained), I decided to take the plunge and bolt it on (which entailed submitting an SSL bug in the process, which got fixed within minutes). It won’t help me with the Python bits, but it provides me with a working playground.
So far, SPDY has been a mixed bag. Given the amount of optimization this site has undergone throughout the years it would be hard to expect dramatic speed improvements (and, after all, I’m across the Atlantic from it, so there’s a little thing called the speed of light that adds a few hundred milliseconds to every request), but having the homepage load over SSL from a cold client cache in less time than via standard HTTP is okay in my book.
Plus there are a few serious annoyances for production sites, such as inconsistent browser behavior:
- Firefox acknowledges the Alternate-Protocol: npn-spdy/2 header and switches over to SPDY, whereas the recent Chrome builds (up to version 20 on my Macs) stubbornly refuse to switch automatically.
- Chrome complains about the Carbon advertisements (even though I’m doing everything possible to fetch them via SSL), whereas Firefox gleefully ignores them and carries on as if nothing had happened.
Given that the Alternate-Protocol header has vanished from draft 3 of the spec and that Chrome’s chrome://net-internals/#spdy shows it defaulting to False, there seems to be no effective way to advertise SPDY support for all browsers (way to go, guys - breaking your own browser?)
Clearly there’ll be a lot to sort out before this becomes feasible in the wild.
As to this site, there might be some more tweaks required, but given that shrpx is talking directly to Varnish’s RAM cache, I don’t think they’ll be performance-related ones.