5 ms·

HAProxy is used for TCP too. The main benefit from my perspective is that there is one less component in the stack. Whereas I would previously need HAProxy runn

by mryan 11y ago

HAProxy is used for TCP too. The main benefit from my perspective is that there is one less component in the stack. Whereas I would previously need HAProxy running alongside NGINX to balance TCP and HTTP, I can now do all of this with NGINX.

daigoba66 11y ago
But why not just use HAProxy? It is often used for plain TCP load balancing (we use it).
- mryan 11y ago
  Because I would still need to run NGINX alongside it to handle HTTP proxying. By removing HAProxy from the stack, I have one less component to manage/maintain/upgrade. I've used HAProxy for a long time and been very happy with it. But, everything else being equal, a stack with n-1 components is better than a stack of n components.
  - hobofan 11y ago
    Why not use HAProxy for HTTP proxying? If you want to drop one component from the stack it could just as well be NGINX.
    - jsmthrowaway 11y ago
      Because HAproxy's ability to work with URLs and headers is close to unusable.
      - jvehent 11y ago
        Surely you must have misread the docs, it's pretty damn powerful.
        jsmthrowaway 11y ago
        I ran 1.4 in production at a 8,000+ QPS social network, have been on a team who submitted patches to Tarreau that are now in HAproxy, and very intentionally put Openresty behind it for HTTP after months of tweaking a very fragile HAproxy configuration with several applications hanging off our property's domain name. I also architected and built a LBaaS product at a well-known hosting provider using HAproxy. I didn't arrive at that conclusion by misreading the documentation and I stand by it. It's also not a knock of HAproxy, it's just a reflection that being intelligent about HTTP is not HAproxy's primary use case. It is awesome for TCP and I exclusively use HAproxy to balance TCP in a protocol-agnostic way. First, doing anything intelligent with HTTP slaughters HAproxy's performance by an order of magnitude because of the way you must configure it. Second, sticking requests to a backend is easy if you have a header that you want to decide upon. If you want to elect a different backend based upon a path component, this is much harder and yields an unwieldy configuration. HAproxy is not designed to operate extensively on HTTP. It is designed to balance quickly and efficiently, and grew HTTP intelligence because people started wanting the convenience of making HAproxy do far more than its core focus. Rather than HAproxy getting smarter about HTTP, I'd much rather have the protocols that service my applications handle themselves and use HAproxy for its bread and butter, TCP availability and balancing. I can then focus on optimizing that using HAproxy's really clever mechanisms, like keeping the entire TCP conversation in kernel memory without reading it out (which you must do to "be powerful," as you say). This also means if I want to support SPDY or HTTP/2 or Websockets, I'm not waiting for HAproxy to support them because I painted myself in a corner. The stack I've deployed at the frontend of every startup I've ever consulted for or operated looks like this: /- [haproxy AZ A] -- [openresty AZ A] [ELB] -- [haproxy AZ B] -- [openresty AZ B] \- [haproxy AZ C] -- [openresty AZ C] This is my Standard Frontend Deployment A. My other Standard Frontend Deployment, B, is if I have the budget and comprises Netscalers because of my experience with them from Google and other companies. Startup/low budget, ELB/haproxy/openresty. High budget, Netscaler and done. We are speaking to years of my own operational experience. I apologize if it sounded like dismissal; I actually think Tarreau would agree with my observation and opinion, if I'm perfectly honest.
        hrez 11y ago
    - notatoad 11y ago
      nginx can do a lot more than just HTTP proxying - it's a pretty popular webserver, and if your stack contains both nginx and haproxy right now, you must be using nginx for something haproxy can't do. So if you use both, you can drop haproxy. If you just need a reverse proxy, there's no reason to replace haproxy with nginx.
- LaSombra 11y ago
  Professional support services is quite important. I don't know if HAProxy provides it but I know nginx does.
  - deleted 11y ago
    [deleted]
  - amenod 11y ago
    They do. [0] And even their nonpaid support was absolutely awesome the one time I needed it. Not conclusive evidence by any means, but I was impressed by the way the bug (/feature request) was handled... [0] http://www.haproxy.org/#supp http://www.haproxy.org/#supp

by mryan 11y ago

daigoba66 11y ago

But why not just use HAProxy? It is often used for plain TCP load balancing (we use it).

mryan 11y ago
Because I would still need to run NGINX alongside it to handle HTTP proxying. By removing HAProxy from the stack, I have one less component to manage/maintain/upgrade. I've used HAProxy for a long time and been very happy with it. But, everything else being equal, a stack with n-1 components is better than a stack of n components.
- hobofan 11y ago
  Why not use HAProxy for HTTP proxying? If you want to drop one component from the stack it could just as well be NGINX.
  - jsmthrowaway 11y ago
    Because HAproxy's ability to work with URLs and headers is close to unusable.
    - jvehent 11y ago
      Surely you must have misread the docs, it's pretty damn powerful.
      - jsmthrowaway 11y ago
        I ran 1.4 in production at a 8,000+ QPS social network, have been on a team who submitted patches to Tarreau that are now in HAproxy, and very intentionally put Openresty behind it for HTTP after months of tweaking a very fragile HAproxy configuration with several applications hanging off our property's domain name. I also architected and built a LBaaS product at a well-known hosting provider using HAproxy. I didn't arrive at that conclusion by misreading the documentation and I stand by it. It's also not a knock of HAproxy, it's just a reflection that being intelligent about HTTP is not HAproxy's primary use case. It is awesome for TCP and I exclusively use HAproxy to balance TCP in a protocol-agnostic way. First, doing anything intelligent with HTTP slaughters HAproxy's performance by an order of magnitude because of the way you must configure it. Second, sticking requests to a backend is easy if you have a header that you want to decide upon. If you want to elect a different backend based upon a path component, this is much harder and yields an unwieldy configuration. HAproxy is not designed to operate extensively on HTTP. It is designed to balance quickly and efficiently, and grew HTTP intelligence because people started wanting the convenience of making HAproxy do far more than its core focus. Rather than HAproxy getting smarter about HTTP, I'd much rather have the protocols that service my applications handle themselves and use HAproxy for its bread and butter, TCP availability and balancing. I can then focus on optimizing that using HAproxy's really clever mechanisms, like keeping the entire TCP conversation in kernel memory without reading it out (which you must do to "be powerful," as you say). This also means if I want to support SPDY or HTTP/2 or Websockets, I'm not waiting for HAproxy to support them because I painted myself in a corner. The stack I've deployed at the frontend of every startup I've ever consulted for or operated looks like this: /- [haproxy AZ A] -- [openresty AZ A] [ELB] -- [haproxy AZ B] -- [openresty AZ B] \- [haproxy AZ C] -- [openresty AZ C] This is my Standard Frontend Deployment A. My other Standard Frontend Deployment, B, is if I have the budget and comprises Netscalers because of my experience with them from Google and other companies. Startup/low budget, ELB/haproxy/openresty. High budget, Netscaler and done. We are speaking to years of my own operational experience. I apologize if it sounded like dismissal; I actually think Tarreau would agree with my observation and opinion, if I'm perfectly honest.
        hrez 11y ago
  - notatoad 11y ago
    nginx can do a lot more than just HTTP proxying - it's a pretty popular webserver, and if your stack contains both nginx and haproxy right now, you must be using nginx for something haproxy can't do. So if you use both, you can drop haproxy. If you just need a reverse proxy, there's no reason to replace haproxy with nginx.
LaSombra 11y ago
Professional support services is quite important. I don't know if HAProxy provides it but I know nginx does.
- deleted 11y ago
  [deleted]
- amenod 11y ago
  They do. [0] And even their nonpaid support was absolutely awesome the one time I needed it. Not conclusive evidence by any means, but I was impressed by the way the bug (/feature request) was handled... [0] http://www.haproxy.org/#supp http://www.haproxy.org/#supp