4 ms·

What's the current (2022) view on HAProxy vs. Nginx? I know the sentiment has changed over the years. Curious what's the opinion today on which is the best too

What's the current (2022) view on HAProxy vs. Nginx? 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)

osrec 4y ago
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.
- ilyt 4y ago
  HAProxy is not a web server in the first place. The only thing it serves, from memory only (need reload to change) are error pages.
  - wtarreau 4y ago
    Or the cache :-) (also "return" directives but that doesn't count).
- wtarreau 4y ago
  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 :-)
emptysongglass 4y ago
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." [1] https://www.nginx.com/blog/nginx-and-haproxy-testing-user-experience-in-the-cloud/ https://www.nginx.com/blog/nginx-and-haproxy-testing-user-ex...
- wtarreau 4y ago
  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/ https://github.com/dpbench/dpbench/ and later to the new test in this article: https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance/ 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.
  - fullstop 4y ago
    Hey, Willy, I just wanted to take a moment of my day to thank you for haproxy. It is among my most favorite tools in my tool belt!
    - wtarreau 4y ago
      Thank you, you're welcome!
the_gipsy 4y ago
I just switched from nginx to haproxy. Nginx just serves http now. Makes things easier for me.
jwcooper 4y ago
I like having haproxy in front of nginx (and other services) as a load balancer. It's fast, easy to tune/configure and cheap to run.
akvadrako 4y ago
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.
- tiffanyh 4y ago
  OpenResty is only available via Nginx Enterprise?
  - mdaniel 4y ago
    Definitely not, Kong (for example) is "OpenResty plus a management plane" and they're Apache 2: https://github.com/kong/kong#license https://github.com/kong/kong#license OpenResty itself is BSD https://github.com/openresty/openresty#copyright--license https://github.com/openresty/openresty#copyright--license
  - akvadrako 4y ago
    I mean some features you get with haproxy are only available with either enterprise or OpenResty.
- ilyt 4y ago
  "paid edition" AFAIK is mostly stuff around haproxy, management and analytics mostly.
ilyt 4y ago
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. * [1] https://www.haproxy.com/blog/extending-haproxy-with-the-stream-processing-offload-engine/ https://www.haproxy.com/blog/extending-haproxy-with-the-stre...
- zinekeller 4y ago
  > 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.
xfalcox 4y ago
Second release of HAProxy with HTTP/3 support. Nginx doesn't support it. HAProxy support 103 Early Hints since 2018. Nginx doesn't support it.
Beltalowda 4y ago
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.
- wtarreau 4y ago
  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.
ipevans 4y ago
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/ https://www.haproxy.com/blog/haproxyconf-2022-recap/ Disclosure: I am part of the HAProxy team.
brimstedt 4y ago
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.
thewataccount 4y ago
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.

osrec 4y ago

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.

ilyt 4y ago
HAProxy is not a web server in the first place. The only thing it serves, from memory only (need reload to change) are error pages.
- wtarreau 4y ago
  Or the cache :-) (also "return" directives but that doesn't count).
wtarreau 4y ago
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 :-)

emptysongglass 4y ago

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." [1] https://www.nginx.com/blog/nginx-and-haproxy-testing-user-experience-in-the-cloud/ https://www.nginx.com/blog/nginx-and-haproxy-testing-user-ex...

wtarreau 4y ago
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/ https://github.com/dpbench/dpbench/ and later to the new test in this article: https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance/ 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.
- fullstop 4y ago
  Hey, Willy, I just wanted to take a moment of my day to thank you for haproxy. It is among my most favorite tools in my tool belt!
  - wtarreau 4y ago
    Thank you, you're welcome!

the_gipsy 4y ago

I just switched from nginx to haproxy. Nginx just serves http now. Makes things easier for me.

jwcooper 4y ago

I like having haproxy in front of nginx (and other services) as a load balancer. It's fast, easy to tune/configure and cheap to run.

akvadrako 4y ago

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.

tiffanyh 4y ago
OpenResty is only available via Nginx Enterprise?
- mdaniel 4y ago
  Definitely not, Kong (for example) is "OpenResty plus a management plane" and they're Apache 2: https://github.com/kong/kong#license https://github.com/kong/kong#license OpenResty itself is BSD https://github.com/openresty/openresty#copyright--license https://github.com/openresty/openresty#copyright--license
- akvadrako 4y ago
  I mean some features you get with haproxy are only available with either enterprise or OpenResty.
ilyt 4y ago
"paid edition" AFAIK is mostly stuff around haproxy, management and analytics mostly.

ilyt 4y ago

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. * [1] https://www.haproxy.com/blog/extending-haproxy-with-the-stream-processing-offload-engine/ https://www.haproxy.com/blog/extending-haproxy-with-the-stre...

zinekeller 4y ago
> 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.

xfalcox 4y ago

Second release of HAProxy with HTTP/3 support. Nginx doesn't support it. HAProxy support 103 Early Hints since 2018. Nginx doesn't support it.

Beltalowda 4y ago

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.

wtarreau 4y ago
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.

ipevans 4y ago

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/ https://www.haproxy.com/blog/haproxyconf-2022-recap/ Disclosure: I am part of the HAProxy team.

brimstedt 4y ago

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.

thewataccount 4y ago

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.