Haproxy 2.2
haproxy.com
haproxy.com
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.
I compiled it from source on our edge servers for a long time (as opposed to packaged), simply so I could apply these real time patches as needed.
[1] https://github.com/haproxy/haproxy/issues/123#issuecomment-5...
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.)
This is why I love HN. I ask a good question and get a lot of great feedback!
HAProxy gives you the following that are musts for load balancing (in my opinion), that NGINX does not, at least not easily:
1) A HTML (or JSON) stats page that precisely and completely tells you what’s going on at a high-level. A visit to this during outages is often all that’s required.
2) Support for DNS (and other) discovery mechanisms in a flexible way. (This is paid in NGINX)
3) Active health checks (also paid in NGINX)
4) The ACL system, while somewhat difficult to learn, is amazingly powerful.
5) Flexible L7 retries are brilliant.
We replaced NGINX with HAProxy and eliminated a whole class of bugs, micro-outages, and annoyances just by following HAProxy’s best practices.
I still use NGINX when I need a static web file server, though. :)
nginx - { static file serving, good proxy for python/ruby apps, req manipulation with advanced scripting capabilities via lua engine through open-resty [mirroring, WAF(naxsi), url rewriting etc] }
A combo of haproxy + nginx would always bring good delight for many practitioners.
All 3 components are free, combine extremely well because they've grown together, and are extremely efficient. This is important in virtualised or containerized environments where you want to save resources to minimize response time and leave the CPU for the applications.
Of course each of them can do a little bit of the other ones' job. This is fine, it allows easier initial deployments, but as your site grows, whichever you initially start with, you'll always end up installing the two other ones to constitute the most robust stack ever. And it's easy to insert one next to the others without having to break everything, which further adds to the fun.
It's great.
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.
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.
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 will definitely checkout out HAProxy now.
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.
To all the developers of such a great piece of software, I offer you my gratitude.
I don't remember the exact details, but the allowed formats of some identifiers were different, and it didn't do "the obvious thing" when the configuration and state file contained a different set of definitions, IIRC. This was consistent, but not very well documented.
It works fine for us now, so we like it, of course, but it took some production incidents to figure out how it all worked. (We did test before shipping, of course, but these were hard-to-predict edge cases.)
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?
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.
Looked up Willy on LinkedIn,"DO NOT SEND ME FCKING INVITES IF WE HAVE NOT WORKED TOGETHER! "
No Fcking around with this guy.
I think plenty of HNers will see that as a positive aspect.
Claiming that an unreadable version of a site is better than a readable one is simply wrong.
Because mobile has been a basic requirement and competency for, say, the last decade.
I would've thought allowing user agent style sheets would be a basic requirement for a web browser but it seems that not everyone agrees with me, and sometimes you just have to accept that not everyone is on the same page as you.
No, I'm a potential haproxy user who is unable to access the site because whoever put it together either failed to follow basic CSS tutorials or has no idea that there are more reading surfaces than 19' 1980x1080 LCD monitors.
And the surprising thing is that here I am, in HN of all places, where readers are expected to be educated and somewhat informed and with a basic understanding, reading comments like yours. Baffling, to say the least.
https://i.imgur.com/Zmslysb.jpg
The text in the navigation section and the table is a bit small, but quite far from unreadable. That can also easily be solved by zooming in.
On the topic of mobile, I think it is also very important to look at data usage.
~327KB for all assets on haproxy.org ~5.8MB for all assets on haproxy.com including nearly a megabyte of javascript
It's information dense, which is much appreciated on desktop. The .com looks like every other generic 'look at our product!' site, and to actually do anything you have to sort through 5 different dropdowns and other UI items designed to grab your attention.
When I have to install or configure the software I want the .org, 100%.
This is where you get it entirely wrong. I read this news and I, as an extensive nginx/traffic user, wanted to check out haproxy to understand if it was worth a shot. The .org page is plagued with general usability and readability problems to the point that it's practically unreadable when compared with the page served through the .com domain. There is no way around it.
You don't fix problems by turning a blind eye and playing the denying card. More importantly, this sort of technical snafu is helps form the public image of the product, and thus this sort of poor performance reflects poorly on the product.
Nobody is swapping out any tech via their mobile browser impression. All this is pretty complicated software and you're going to want to do a lot of reading/inspection before making decisions like that. That is not done via a 5" display.
I stand with my view that there is no problem to fix here. The site is clear & understandable to anyone who seriously plans on using it or is using it.
body { max-width: 70rem; margin: 2rem auto; }
As one of the other posts kinda suggested you can get a ton done with a few hours, it might be worth just standing up a box real quick and trying it out. As a note when we try stuff like this we put behind a AWS LB so we can push partial traffic to our experiment and aren’t betting the farm whilst testing in prod.
Good luck!
Anyone managed to make this work on haproxy?
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.
Nowadays we forward the TPU pods to pretty much anyone who wants to try them out, in hopes of getting more people involved in the TPU programming scene. The TPUs are managed via a website (https://www.tensorfork.com/tpus) and we coordinate TPU access via spreadsheet. Each researcher has their own GCE project, and we simply flip a switch to give them access.
If anyone reading this happens to be into ML and into programming for big hardware rigs, feel free to hop into the Tensorfork discord server and we can show you the ropes. https://github.com/shawwn/tpunicorn#ml-community
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.
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.