Hacker News Reader

Comment by wensheng | Hacker News Reader

Haproxy supports websocket. What are the advantages of using Hipache instead of Haproxy?

HAProxy isn't designed to serve thousands of different virtual hosts. If you have a handful of different domains, that's fine, you can use some ACLs on the HTTP "Host:" header to differentiate them; if you have thousands of apps, and need an easy way to reconfigure dynamically, Hipache is more appropriate.

- SSL termination.

- Support for persistent (keep-alive) connections. A small detail which bit me when I deployed using Haproxy: it sets the X-Forwarded-For header only for the first request. Subsequent requests on the same connection will not include that header.

I'm a bit late on the discussion, but one advantage that I can see is that Hipache adds the HTTP_X_FORWARDED_FOR header, something that the Haproxy author refuses to do (perhaps for good reason, I'm not sure).

I second this question.

To quote the github page [1], Hipache is "a distributed proxy designed to route high volumes of http and websocket traffic to unusually large numbers of virtual hosts, in a highly dynamic topology where backends are added and removed several times per second. It is particularly well-suited for PaaS (platform-as-a-service) and other environments that are both business-critical and multi-tenant".

Before building Hipache, dotCloud's network routing layer consisted of a large number of boxes running nginx, wrapped in a custom instrumentation and management layer which, among other things, generated configuration files of mind-boggling size several times per minute and propagated them across a fairly complex distributed system. If we had used haproxy, we would have had to adapt that ad-hoc instrumentation layer to haproxy - not a particularly pleasant prospect. Since dotCloud had reached a scale which mandated a redesign of the routing layer anyway, we killed two birds with one stone.

http://github.com/dotcloud/hipache

Reply on news.ycombinator.com