Live data from Hacker News

Haproxy 2.2

haproxy.com

11–20 of 61 posts

Re: Haproxy 2.2

#11
post #4

Haproxy is such a nice piece of software, sensible configuration, very stable and versatile. And, one thing that is highly appreciated, I've never seen it do something I wasn't expecting it to. This quality of minimal surprises in its operation isn't going unnoticed by any measure.

Has it solved the reloading problem yet?

Yup, https://www.haproxy.com/blog/hitless-reloads-with-haproxy-ho...

Re: Haproxy 2.2

#13

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.

IPtables does 0.1% of what Haproxy can do.

Re: Haproxy 2.2

#14
post #10

It's amazing how much better the .org site is over the .com.

Isn't it the other way around? Haproxy.org is not responsive and looks like it was designed in the 90s.

> looks like it was designed in the 90s.

I think plenty of HNers will see that as a positive aspect.

Re: Haproxy 2.2

#15
post #6

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.

Just curious, what were you doing where you needed the performance of iptables over haproxy?

I've done some dead simple forwarding/load balancing work, and if you can do it with nat instead of a proxy application it'll use a lot less memory, in addition to less cpu.

That means fewer load balancers needed, or smaller machines (or both). So I'd say that means anytime you run out of capacity on your proxy machines would be an opportunity to look for other techniques. Haproxy is probably easier to use though, and would tend to need less work to get the features you want, though. So there's an opex/capex vs development time argument.

Hyperscaling Haproxy is a lot of fun too, though. There's a huge difference in connections/second between a normal config and a totally tuned config with haproxy and kernel patching on the table.

Re: Haproxy 2.2

#17
post #14

Earlier quoted context omitted.

Isn't it the other way around? Haproxy.org is not responsive and looks like it was designed in the 90s.

> 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.

Re: Haproxy 2.2

#18
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 how HAProxy could be better for my company’s rather unique needs.

I often feel bad that I cannot do more for the project, because it is so well thought-through and delivered.

The software cuts no corners and delivers at fractions of the TCO of competition (limited by my opinion and experience, of course). For instance, just last week, I spun a rate limiting solution in half a morning, that mitigated some annoying proxy bots instantly (and is flexible enough to automatically block offenders without affecting legitimate users).

The stats, DNS support, and integrations and many other featured are second to none among other load balancers.

It’s an impressive and refreshing project. We could all learn something from HAProxy and the team.

Re: Haproxy 2.2

#19
Slightly OT, we have several different kinds of services that need rate limiting, written in different stacks. We would like to have one solution for rate limiting, ideally that we could put in front of any service, that was light weight, but also could work with AWS target groups that are already splitting traffic across nodes inside a service - so I believe that means some sort of clustered solution or at least communication. Is haproxy a good fit for this? Maybe nginx (paid)?

Re: Haproxy 2.2

#20
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 content over the same socket. There are also lots of other custom protocols that benefit from this type of set up, including one that I'm working on wrangling HA Proxy to work with now.

Does anyone know if there's some replacement way to handle this in HA Proxy that I'm overlooking?

Post reply on HN