A common request we get from readers is to describe in more detail how our server infrastructure is setup. That question is so incredibly broad that it’s hard to answer it in any kind of comprehensive way, so I’m not going to try to. Instead, I’m keeping the general desire for more technical details in mind as I work through day-to-day issues with our configuration, and I’ll try to occasionally write about things that I think might be of interest. The topic for today is HAproxy.

HAproxy is a load balancing proxy server that we use between our front-end web servers (Apache) and our back-end application servers (Mongrel). It allows us to spread the traffic for dynamic content among a number of application servers and deals with things like failover if any of the individual Mongel instances happen to be down.

There are a lot of software load balancers out there and we’ve tried a number of them. Some of the reasons we finally ended up going with HAproxy include:

  1. Speed. It’s really, really fast.
  2. It’s efficient. One of our instances is handling around 700 requests per second and using less than 5% CPU and only around 40MB of RAM on the Xen instance that it’s running on.
  3. It allows us to make configuration changes gracefully, without breaking any existing connections.
  4. It allows us to queue requests up if all of our Mongrels are busy.

Of these, the last item is the killer feature for our purposes.

I’ll let you in on a secret—this post has been hanging around for a couple of months now and I’ve tried several times to come up with a good way to describe how the queueing works, but I’ve never been satisfied with the results. With that in mind, I decided to take a page from the 37signals Live playbook and do a brief screencast to illustrate the power of this feature.

I plan to write more about our infrastructure as time permits. If there are particular topics that you’d like to see covered in a future installment, please email svn@37signals.com.