5 ms·

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 plug

by hrez 10y ago

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.

Forbidden 10y ago
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 https://www.youtube.com/watch?v=yQvcHy_tPjI
- takeda 10y ago
  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#observe http://cbonte.github.io/haproxy-dconv/configuration-1.6.html... [2] http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#on-error http://cbonte.github.io/haproxy-dconv/configuration-1.6.html...
  - hrez 10y ago
    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.

by hrez 10y ago

Forbidden 10y ago

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 https://www.youtube.com/watch?v=yQvcHy_tPjI

takeda 10y ago
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#observe http://cbonte.github.io/haproxy-dconv/configuration-1.6.html... [2] http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#on-error http://cbonte.github.io/haproxy-dconv/configuration-1.6.html...
- hrez 10y ago
  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.