I'm not entirely disagreeing with your post, but there's a few comments I'd like to make. 1) HAproxy does support SPDY, now via NPN/ALPN. And you don't need h

I'm not entirely disagreeing with your post, but there's a few comments I'd like to make. 1) HAproxy does support SPDY, now via NPN/ALPN. And you don't need http mode for this. 2) HTTP performance (and performance in general) is now much better. Particularly on newer kernels (IIRC somewhere in the 3.12-3.15 range, when splice was fixed for small objects). 3. I'm not sure why you found it fragile. I've run HAProxy in HTTP mode at much higher QPS volumes than you were seeing - this did require a bunch of tuning, and I'm actually hoping to have time sometime in the next few weeks to write some articles on doing this. But it worked, and worked well. What's worked well for me is the following: /- [haproxy] [router] -- [haproxy] \- [haproxy] Using anycast routing to distribute the load over the haproxy servers, who run BIRD[1]. It's simple and pretty effective - although you want to chose your router hashing method carefully, and if you use persistance (stick tables) you have to use a recent version of haproxy, with support for peering. It is difficult to make it work, though - just how difficult I only recently appreciated when trying to help a friend over IRC make haproxy scale to very high volumes. I'm hoping that I'll find the time to write the articles I mentioned above, which will hopefully be useful to others with this sort of problem to solve. 1: http://bird.network.cz/ http://bird.network.cz/