Live data from Hacker News

NGINX open sources TCP load balancing

hg.nginx.org

41–50 of 121 posts

Re: NGINX open sources TCP load balancing

#41
post #30

Earlier quoted context omitted.

Why not use HAProxy for HTTP proxying? If you want to drop one component from the stack it could just as well be NGINX.

Because HAproxy's ability to work with URLs and headers is close to unusable.

Surely you must have misread the docs, it's pretty damn powerful.

Re: NGINX open sources TCP load balancing

#42
post #18

Earlier quoted context omitted.

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.

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

Professional support services is quite important. I don't know if HAProxy provides it but I know nginx does.

Re: NGINX open sources TCP load balancing

#46

Can someone explain how this is superior to HAproxy?

HAProxy's primary feature is HTTP/HTTPS load balancing. This new feature competes only with HAProxy's TCP load balancing support. Note that Nginx already has a simple proxy built in that does very basic HTTP load balancing. HAProxy's is vastly superior to Nginx's in that it supports a sophisticated set of filters ("ACLs"), transformations (eg., header rewriting), queue behaviours (eg., queue limits, backup backends,…

Thank you!

Re: NGINX open sources TCP load balancing

#47
post #14

Many installations would go from haproxy->nginx to nginx->nginx. Having to support a single product will make many devops happy. In the same tense, haproxy is adding Lua support[1], which has been available in nginx - using openresty[2] - since 2011, and nginx core is doing the same with Javascript[2]. Interesting times aroung haproxy and nginx. [1] http://blog.haproxy.com/2015/03/12/haproxy-1-6-dev1-and-lua/ [2] htt…

Not sure about that... HAproxy is a proven technology (very reliable and a joy to use at that) in this field while Nginx is a newcomer and needs to establish its credibility first. I personally wouldn't use such technology for load balancer until it is properly battle-tested. Also, I can't see much of an advantage over (proven) HAproxy - am I missing something?

As for supporting a single product, I don't see the point of that. Using Nginx for load balancing will probably be much different than using Nginx as a web server, so the learning curve is similar.

Not that I don't welcome competition, I just don't see a real need in this space.

EDIT: btw, the Lua thing was an April Fool's joke...

EDIT 2: no it wasn't, my mistake. I was surprised by this so I checked the page and jumped a gun when I saw "April 1st" on http://www.haproxy.org/news.html. Sorry about that...

Re: NGINX open sources TCP load balancing

#48
post #39

Earlier quoted context omitted.

HAProxy's primary feature is HTTP/HTTPS load balancing. This new feature competes only with HAProxy's TCP load balancing support. Note that Nginx already has a simple proxy built in that does very basic HTTP load balancing. HAProxy's is vastly superior to Nginx's in that it supports a sophisticated set of filters ("ACLs"), transformations (eg., header rewriting), queue behaviours (eg., queue limits, backup backends,…

Actually, Nginx has a couple of different load balancing algos that you can pick from -- http://nginx.org/en/docs/http/load_balancing.html

I wasn't aware of that. Thanks.

Re: NGINX open sources TCP load balancing

#49

Earlier quoted context omitted.

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

Professional support services is quite important. I don't know if HAProxy provides it but I know nginx does.

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

Post reply on HN