Hacker News Reader

Hacker News

Comment by pritambaral | Hacker News Reader

Full thread

pritambaral

My favourite bits in this release:

1. Fix of the repeated-tries of non-idempotent requests bug.

2. Dynamic modules.

3. HTTP/2!!

4. reuseport in listen.

5. SSLv3 disabled by default.

6. UDP Load Balancing.

View on HN

> UDP Load Blancing

Isn't that just a feature creep?

Doesn't look like anything that would be useful in a web server and load balancing of UDP is different than TCP. Layer 3 load balancing (e.g. LVS) would probably be more suitable.

Nginx is not a web server. Nginx is a reverse-proxy.

Nginx's sees a massive share of its usage as a web server, sure, but – from the very beginning – it was always intended to be a good reverse-proxy.

Apart from http, nginx also supports mail (imap, pop3, smtp), stream sockets (tcp and unix), and few third-party ones too (like rtmp). And now, UDP as well.

One of most needed features expected of a good reverse-proxy is load-balancing. Nginx is already quite good at it, but lacked UDP load balancing (like HAproxy – another reverse-proxy – does). That is no longer the case, and I'm sure the people that have asked HAproxy to support UDP will be pleased that nginx does it now.

I suppose its support for static content and other HTTP-ish-server features mislead people. I use it, saw the mail stuff and figured it was "weird". Had no idea it could do general TCP proxying.

For reverse-proxy/LB it kinda sucks. No standard healthchecks for a long-long time and nowdays only in commercial version? Yes, you can compile in 3d party plugin but that just underscores the lacking.

You're completely wrong. Opensource version has always had in-flight healthchecks that work just perfect, see: https://www.youtube.com/watch?v=yQvcHy_tPjI

1. He's not wrong, those are not healthchecks, essentially when connection fails (nginx immediatelly tries next server) this works well when service is stopped and host sends response that the port is closed. It fails miserable when host is actually down (which is what happens most of the time in real world). This also won't help you when the server is up and application is broken and returns errors, which is another very common scenario.

2. This test is unfair, it relies on default settings, where nginx has defaults to retry immediately and never give up. HAProxy by default has this option (option redispatch) disabled because it offers larger range of load balancing algorithms and in some cases this setting might not make sense. The point is that you can configure it to behave the same way.

3. In terms of in-flight health checks HAProxy has actual ones (in addition to the above redispatch mechanism) with observe option[1] and on-error[2] it can be programmed to for example simulate healthcheck down when application generates too many 5xx errors.

[1] http://cbonte.github.io/haproxy-dconv/configuration-1.6.html...

[2] http://cbonte.github.io/haproxy-dconv/configuration-1.6.html...

Yep, serving 503 or otherwise broken app to users is not acceptable LB behavior. Nginx aficionados fail to comprehend that somehow. Which I guess shows that nginx is web server first and proxy/LB second.

As a reverse proxy though, it is hardly the best, either in performance or compliance. As far as in creating an (unjustified) reputation for itself, it is superior.

www.slideshare.net/bryan_call/choosing-a-proxy-server-apachecon-2014

www.slideshare.net/AllThingsOpen/battle-of-the-stacks

Just for the information: Jim Jagielski, the director of Apache Foundation, who won't miss any opportunity to say how he hates nginx, and how bad nginx is. Well done!

It's called "Battling FUD" :-)

Since those are slides without the actual talk, any idea why HAProxy was excluded in many comparisons?

It feels a bit biased.

Dynamic modules will be the best thing since sliced bread. I have wanted to use a StatsD plugin for metrics but having to manually compile has kept me from doing so for 2 years. I don't want that technical debt sticking around.

Sounds like you should be automating more stuff, there is little reason compiling something like nginx should cause technical debt. Especially since nginx versions in stable distros are usually really old versions, and when it comes to security take a while to get patched up.

While thats true that it could be more automated, its a whole lot easier to automate an "apt-get install nginx-statsd" than manually compiling and having to make sure it doesn't break between versions. Basically I don't want to "own" the process.

It's like the old joke: New linux users use the default kernel of a distro because it 'just works', power users compile their own kernel to get every drop of performance, and senior users use the default kernel because it 'just works'...

Yup, plus you get the benefit of thousands of other people running the exact same setup which helps report/fix bugs.

HTTP/2 has been available for a while now. iirc, SSLv3 has also been disabled for a while.

TFA is a stable channel announcement. Everything in it has been available for a while now, but under the mainline channel. Like a new release of Ubuntu getting Linux 4.4 while Arch and Gentoo are on 4.5 already.

Reply on news.ycombinator.com