Why do you choose HAProxy over Ngxinx? It's sounds like you love it, and I have had no experience with HAProxy. So I'm curious about the reasons you love it. (Just to be clear this is a sincere question to learn since tone is hard to express clearly with text.)
One good reason is that HAProxy doesn't payment gate a bunch of the baseline features. I'm still surprised that NGINX doesn't come with active healthchecks in the free version - baseline feature for a load balancer in the world of treating computers as cattle. HAProxy is such a great example of software that does what you expect, generally.
> HAProxy is such a great example of software that does what you expect, generally.
It's also rock solid and battle tested. I don't think I ever observed crash. It's typically one of tools that once you configure correctly it works for years without issues.
HAProxy is a unique piece of software. I’ve had the privilege to interact directly with Willy (the main developer for many years, still the project lead) on the mailing list, in person at the conference, and even though I’ve never paid a dime, the interaction has been the best open-source experience I’ve ever had. Willy routinely writes multi-paragraph responses on the mailing list to my hair-brained suggestions for…
Why do you choose HAProxy over Ngxinx? It's sounds like you love it, and I have had no experience with HAProxy. So I'm curious about the reasons you love it. (Just to be clear this is a sincere question to learn since tone is hard to express clearly with text.)
I switched reddit from nginx to haproxy because nginx had a pathological problem where it would send 90% of the load to the first app server listed when there was a burst of requests (and 9% to the next, and .9% to the next and so on, leaving almost every app server idle).
I'm sure they fixed the problem by now, but it was not a good look for a load balancer.
HAProxy on the other hand has never failed me, and Wily (the creator) is super responsive if you have questions or need features.
One good reason is that HAProxy doesn't payment gate a bunch of the baseline features. I'm still surprised that NGINX doesn't come with active healthchecks in the free version - baseline feature for a load balancer in the world of treating computers as cattle. HAProxy is such a great example of software that does what you expect, generally.
> HAProxy is such a great example of software that does what you expect, generally. It's also rock solid and battle tested. I don't think I ever observed crash. It's typically one of tools that once you configure correctly it works for years without issues.
> I don't think I ever observed crash.
It got a lot better quickly, but running with thread was crashy with a lot of threads. I don't remember crashes with single threaded/forking mode though, and I ended up with a forking config when I was setting something up at my last job.
Haproxy isn’t quite as fast as iptables (we switched because of this) but it was delightful to configure. The tradeoff is definitely worth it in most cases.
That's because iptables do layer 3 load balancing (on a kernel level) while HAProxy does layer 7 (on user level). Layer 3 load balancing is much simpler so there's less work to do. If layer 3 load balancing does work for your use case then HAProxy wasn't the right tool.
BTW: Willy Tarreau (the author of HAProxy) is also a Linux kernel developer and made contributions in those areas, so . If you configure HAProxy to do zero copy forwarding you can get quite good performance.
> looks like it was designed in the 90s. I think plenty of HNers will see that as a positive aspect.
I understand the nostalgia or liking the retro look, but the site is completely unreadable in mobile. There is absolutely no redeeming quality in that. Claiming that an unreadable version of a site is better than a readable one is simply wrong.
It's completely readable on my mobile. (Android running Firefox beta).
The only open source software better than Haproxy is redis IMHO.
I agree that Redis is "good", I wouldn't put it at the level of HAProxy - particularly when it comes to "what stuff is deliberately kept out of the open source version".
If I had to choose a project/tool to put at a similar 'level' as HAProxy in terms of: doing one thing well; a working open source project with a private company backing it; and a well run project, I'd say it's Varnish, which just happens to pair very well with HAProxy.
HAProxy is a unique piece of software. I’ve had the privilege to interact directly with Willy (the main developer for many years, still the project lead) on the mailing list, in person at the conference, and even though I’ve never paid a dime, the interaction has been the best open-source experience I’ve ever had. Willy routinely writes multi-paragraph responses on the mailing list to my hair-brained suggestions for…
Totally agree. HAproxy is an incredible piece of software. It is both extremely fast, and very versatile, which is a rare combination. The 2.2 release checks off almost every item on my haproxy wishlist, which makes me very happy.
To all the developers of such a great piece of software, I offer you my gratitude.
I love HA Proxy, but one thing I'm confused about is why the http-tunnel feature was removed in this release (and deprecated in earlier 2.x releases). http-tunnel allowed you to start a session with an HTTP request/response, then keep the socket to the backend alive without further inspection of the protocol. This is useful for things like RTSP where you kick things off with HTTP but then stream lower level TCP conte…
> why the http-tunnel feature was removed in this release
From the haproxy 2.0 documentation:
> This mode should not be used as it creates lots of trouble with logging and HTTP processing. And because it cannot work in HTTP/2, this option is deprecated and it is only supported on legacy HTTP frontends. In HTX, it is ignored and a warning is emitted during HAProxy startup.
As for a way to handle this, I believe if you are using an HTTP CONNECT or a websocket (Connection: Upgrade), then haproxy will detect that it is a tunnel, and handle that correctly. If that's not the case, you might be able to use haproxy in tcp mode.
Why do you choose HAProxy over Ngxinx? It's sounds like you love it, and I have had no experience with HAProxy. So I'm curious about the reasons you love it. (Just to be clear this is a sincere question to learn since tone is hard to express clearly with text.)
Why you chose Nginx over HAProxy? I see a lot of people preferring Nginx, but I can't understand why they are so fascinated about it and try to squeeze it where it has no place. Nginx is just a web server that has some load balancing functionality, it is sub par with HAProxy. I never seen people saying why are you using HAProxy instead of Apache, but Nginx load balancing functionality is closer to Apache than HAProxy…
I think people choose nginx because it does everything decently, even if it can't beat HAProxy for load-balancing or Varnish for caching (at least the FOSS nginx). I run a small-to-mmedium size application with multiple upstream (local web app tier, remote asset servers) and some basic vhost and caching use-cases, e.g. cache specific paths with different cache keys than others, different cache behaviours and life-times, request rate limiting, some local file serving. nginx does everything I need, without any additional modules. I get close enough to zero-downtime deployments by using multiple backends and proxy_next_upstream, haven't needed active healthchecks for the upstreams yet. I have JSON access logs, so my dashboard about vhost activity is in Kibana now. There are a few juicy features missing (cache PURGE, proxy request coalescing, extended stub status endpoint, JSON error log). Not trying to fanboy, but I wouldn't introduce additional complexity into my stack by running haproxy + varnish + nginx just to get the best of each tool, not at my current scale.