I've been using Varnish instead; while "caching proxy" was/is the main tagline of Varnish, there's significant overlap with HAProxy and Ngix as well and Varnish works well even if you just want to do generic proxying/load balancing without any caching.
I really like Varnish's VCL configuration; something like HAProxy's more declarative configuration is easier to get started with, but in more advanced configurations the HAProxy declarative configuration becomes "declarative in name only" where you're embedding logic in the "declarative" configuration. I found it pretty awkward and VCL just becomes so much easier because the logic is expressed "directly" rather than through a declarative configuration. Varnish also comes with some tools to inspect/log requests, which can be handy for debugging Weird Issues™ at times.
Nginx kind of sits in between VCL's full-on DSL and HAProxy's configuration.
I don't know about the exact performance comparisons; Varnish has always been "fast enough" for me. I have a $5/month Linode VPS running Hitch and Varnish and thus far that's been enough for my ~1M requests/day with plenty of room to spare.
I agree with you. Varnish is made for being a website cache that's a real part of the application. It needs to be extremely flexible and programmable. HAProxy needs less flexibility on the caching stuff but more on the conditions to switch a server on/off, regulate traffic or deal with DDoS. Nowadays we see a lot of combinations of the two, initially to get SSL offloading at the haproxy layer, but also for cache deduplication: when you configure haproxy to perform load-bounded consistent hashing to your varnish caches, you get a very efficient cache layer that avoids duplication unless the load starts to grow for some objects in which case these objects will be fetched from adjacent caches. That delivers the best power: unified storage with replication of highly loaded objects only. The cache in haproxy was initially called the "favicon cache" because we don't want it to become a complex cache. And we've succeeded at this, nobody ever manages nor flushes that cache. It's strict and in case of doubt it will refrain from caching. You can use it to avoid passing certain tiny requests to varnish when the cost of passing them over the network outweights their benefit (e.g. favicon or tiny gif bullets that compose pages). But varnish definitely is the de-facto standard cache. The 3 components you name are so commonly found together that some people tend to confuse them (due to the small overlap), but they all excel in their respective areas.
My point was mainly that Varnish can often serve as a complete replacement for HAProxy, rather than a complement to it. No doubt there are features/things in HAProxy that are not easily expressed in Varnish (although in principle you can do pretty much anything in Varnish since you can extend it), but for many common use cases Varnish will work as a fine load balancer, eliminating the need for HAProxy altogether. The only additional thing you need is something like Hitch or Pound to do TLS.
OK I see. Yes for some use cases that's possible. But that seriously limits your load balancing capabilities. And having to deploy Hitch or Pound for TLS still requires an extra component that's not designed to deal with traffic spikes, denial or services etc that are often met in environments where you deploy caches.
I don't know HAProxy that well yet, but I think that Nginx "the company" has degraded severely since purchased by F5.
I used to use nxinx plus, but after moving to a new company and trying to purchase it again, not only had the price quadrupled. I also wasn't able to actually buy a license without four meetings, a shitload of mails and a lot of frustration.
In the end I gave up and kept the community edition while I explore the options.
Nginx clearly moved from the cheap and performany segment to the expensive and cumbersome.
HAProxy have always been better proxy (front traffic, distribute it via rules to other stuff, mangle some headers and such to fix stuff that app refuses to etc.) but it lacked a lot on terms of programmability, with Lua addition and SPOE[1] it gained a lot on that front.
Then again, if you already use nginx (say for serving static files), using it to also front your app is the easiest solution and you only need to start wondering about alternatives once you hit a lot of traffic. Any benefits or drawbacks would only show once you start shoving in massive amounts of traffic, and your app will be bottleneck way before that.
> Then again, if you already use nginx (say for serving static files), using it to also front your app is the easiest solution and you only need to start wondering about alternatives once you hit a lot of traffic. Any benefits or drawbacks would only show once you start shoving in massive amounts of traffic, and your app will be bottleneck way before that.
This. Unless you're serving to tens of millions of users just use the thing that you're comfortable with.
I would say HAProxy is a better load balancer, than a web server. I like to have a few NGINX instances as the actual web servers sitting behind a HAProxy instance that spreads load across them.
I definitely agree. If you need the best load balancer, take haproxy. If you need the best web server, take nginx. The two combined work amazingly well together, that's why they're very often found together :-)
haproxy has a lot of features in the free edition which are only in nginx enterprise, like balancing load by number of open sessions, or OpenResty, like lua scripting.
These days I always go for haproxy for reverse proxying.
We've used HAProxy for load balancing and High availability systems with failover for postgres and redis.
Then we've used Nginx behind that as the Reverse Proxy, static media serving, and basic static caching.
Basically HAproxy seems better for well... High availability and as a load balancing proxy. And Nginx has seems to be more suited for the HTTP(s) type pipeline.
You if all you need is basic load balancing, or some types of HA, then nginx will work fine. Last I checked (few years ago) nginx has a lot more http routing tools and http focused settings, headers, static file serving, etc. But HAProxy might have improved in the last 3 years with those.
This is very biased because it's published by NGINX[1]:
"NGINX suffers virtually no latency at any percentile. The highest latency that any significant number of users might experience (at the 99.9999th percentile) is roughly 8ms.
What do these results tell us about user experience? As mentioned in the introduction, the metric that really matters is response time from the end‑user perspective, and not the service time of the system under test."
Hehe read till the end with the comments, especially the collapsed graphs!
There were big mistakes in this test, failing on a large number of settings, and even the NGINX tests were not as good as they ought to be in some aspects. This conducting Amir, Libby and I to join efforts on documenting better methodology for benchmarks, that we published under the Data Plane Benchmark project at https://github.com/dpbench/dpbench/ and later to the new test in this article: https://www.haproxy.com/blog/haproxy-forwards-over-2-million...
This was great and productive cooperation between engineers, despite working on different (and sometimes competing) projects, resulting in more reliable methods for everyone in the end.
At HAProxyConf last month, a lot of the community members presenting on stage explained why they chose HAProxy over alternatives like Nginx. Benchmark performance was a big part of it, but so was the community. LinkedIn said they compared HAProxy with Nginx, Envoy, and Zuul, and chose HAProxy because of the open-source model, the roadmap and release cycle, and all the features available in the non-Enterprise version. You can see some of their slides and performance benchmark results in this conference recap: https://www.haproxy.com/blog/haproxyconf-2022-recap/
I know the sentiment has changed over the years. Curious what's the opinion today on which is the best tool for a new project.
(Yes, I realize they do different things but there's also considerable overlap as well)