5 ms·

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

anon1685 14y ago
- 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.
amirmansour 14y ago
I second this question.
- shykes 14y ago
  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 http://github.com/dotcloud/hipache
jpetazzo 14y ago
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.
mattparlane 14y ago
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).

- 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.

amirmansour 14y ago

I second this question.

shykes 14y ago
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 http://github.com/dotcloud/hipache

jpetazzo 14y ago

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.

mattparlane 14y ago

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).