What’s new in HAProxy 1.6 | Hacker News Reader

What’s new in HAProxy 1.6

blog.haproxy.com

191 pointsoldmantaiter40 comments

External check pleases me greatly, but sending emails for me seems to be overkill, there are well established ways to do this in unified manner (logparsers, snmp traps etc). Half way trough to fullfill Zawinski's Law.

Yeah, there's a mix of awesome and what? stuff.

> Since 1.6, HAProxy can forge SSL certificate on the fly! Yes, you can use HAProxy with your company’s CA to inspect content.

> Device Identification

(Considering it seems you need a proprietary lib)

> mailers

> lua

> Processing of HTTP request body

All seem to be be moving away from what HAProxy is/was. It's not an application server. It's not a webserver. It's not a mail server.

Lua is kinda awesome, though. Use it with plenty of common sense and it can be a very powerful tool.

I guess part of my concern with Lua was the example on the linked article. It seems to be able to interface with most of the system and not just as a content source, which makes more sense.

FWIW I recently became aware of Pen:

https://github.com/UlricE/pen

I've not tried it - but there should be some overlap in use-cases, and it would appear to be a much smaller project than HAProxy.

Cool, now we can use Device Identification feature to route mobile users to a different backend, also love the HTTP/2 connection sharing.

As always I'm skeptical of reliable device identification. Claiming to have it almost sounds like claiming to own a hen that lays golden eggs. Their blurb about it doesn't do much to convince me so far:

    Through our company, we have some customer who want us to integrate
    into HAProxy the ability to detect device type and characteristics and
    report it to the backend server. We got a couple of contributions from
    2 companies experts in this domain: 51 degrees and deviceatlas. You
    can now load those libraries in HAProxy in order to fully qualify a
    client capabilities and set up some headers your application server
    can rely on to adapt content delivered to the client or let the
    varnish cache server use it to cache multiple flavor of the same
    object based on client capabilities.

    More on this blog later on how to integrate each product.

But it would be a nice surprise if it performed well.

Speaking for DeviceAtlas in particular I can assure you that detection reliability is better than most assume. The stated 99% detection accuracy rate isn’t marketing speak—it is continously verified on real traffic from all around the world.

We measure two main aspects of performance:

- Per-request detection overhead: Willy’s preferred way to measure impact on HAProxy performance is the per request overhead added. DeviceAtlas adds a few µs per request. Typically this does not cause much of an issue. Example: if a load balancer is serving 20,000 requests per second with 80% CPU, that's 40µs of CPU time per request on a machine that can go up to 50µs. If we add 4µs to that we reach 88% of CPU under the same load, and the end user performance is not degraded in any meaningful way.

- Memory footprint: DeviceAtlas lets you configure the per-device property set to tailor the memory and performance impact. The resulting memory impact ranges from about 12MB to 100MB.

Whenever I see a long list of features like these, especially something major like Lua integration, I always wonder, what was given up in the process of adding them? Normally when there's a performance bump, they show the numbers. In this case there's no numbers. Was there a performance hit? Negligible?

I'm surprised to see lua, and to see 1.6 released so quickly. 1.5 took forever to finalize and SSL termination was heavily debated because it wasn't a fast or lightweight like the original goal of HAProxy was. While I realize I don't have to use the lua scripts, it just feels out of place.

EDIT: I guess part of my concern with Lua was the example on the linked article. It seems to be able to interface with most of the system and not just as a content source, which makes more sense.

Willy might not agree, and this isn't really a criticism, but I think 1.5 simply got out of hand — he did a lot of (much-needed) architectural cleanup that took a long time to complete, but along the way a lot of new features (and subsequent bug fixes) got piled onto the same branch and intermingled with the cleanup work.

It's one of those "take apart your airplane and put it back together again" projects that one generally shouldn't do, though sometimes there is no way around it. If you need to rearrange the whole internal architecture of your engine, you should it do it quickly and not mix it with new work.

If you don't use it there is not reason to get a performance bump. Nginx is also using Lua to extend features.

Since Nginx started to add more and more features to their loadbalance it makes sense for HAProxy to get a scripting engine.

As an HAProxy user, support for logging to stdout (and hence journald) would be great. Currently HAProxy users on the major Linux distros either have to use it in debug mode or have a second log server just for the purposes of running HAProxy.

Otherwise I love HAProxy!

what about this type of configuration:

  global
    log /dev/stdout local0 info

It expects a syslog socket, hence the syslog facility names (uucp, fax, local0, etc). Trying the config you suggested:

    [ALERT] 286/160528 (20831) : sendto logger #1 failed: Connection refused (errno=111)

HAProxy is not linux-specific. We have a POSIX logging facility, and HAProxy works just fine with syslog. If journald has problems with syslog, it's basically journald's problem.

stdout isn't Linux specific, and it's all that's needed.

Edit: solved this one myself with a little research. Systemd also implements the /dev/log Unix domain socket (even with the silly syslog facility names, without needing syslog installed) - so:

    global
            log /dev/log local0 info

I've added this as an answer on Stack and try and get it into the docs for anyone else.

In the spirit of avoiding code duplication and making daemontools-like process supervisors happy (that includes systemd for these purposes), I greatly appreciate when logs can be sent to stderr

If the admin wants the logs in syslog, 2>&1 | logger or similar. If the admin wants to use multilog, s6-log, or journald, that's also easy.

(For the same reasons, daemons should not include daemonization routines but should run in the foreground. If I want it in the background, I'll arrange for my process supervisor to start it.)

> (For the same reasons, daemons should not include daemonization routines but should run in the foreground. If I want it in the background, I'll arrange for my process supervisor to start it.)

If a daemon doesn't... daemonize into the background, it's no longer a daemon - just a process.

Silly loonix folks.

Please see the FreeBSD program daemon[1] or the FreeBSD handbook section 3.8[2].

[1] https://www.freebsd.org/cgi/man.cgi?query=daemon&apropos=0&s...

[2] https://www.freebsd.org/doc/handbook/basics-processes.html

The freebsd daemon tool is exactly what I'm talking about. Debian has start-stop-daemon [1]. Process supervisors like daemontools create daemons simply by fork+exec by virtue of the parent process already being a daemon. There's no reason for every service to implement its own daemonization routine.

[1] http://man.cx/start-stop-daemon%288%29

Something I've always wanted to do but from what I can see is impossible in Apache is simply limit the number of connections a single IP can have open at once.

Is this possible with HAProxy? If it is, the documentation doesn't make it clear how.

Well its possible with nginx for sure, havent used apache in about 10 years now (first lighttpd then nginx) i think, after switching to nginx no going back.

Haproxy btw is fantastic too, useful for hiding real location of web server from attacks

Nice. It supports lua and mail alerts on changing servers now...

The mail thing seems like a not healthy growth of functionality.

Most people already have logging infrastructure in place for this.

Unix philosophy and all that.

Sending email alerts probably take very little code. Receiving mail is where the complexity is.

Neither seems like good functionality to add to HAProxy. They both seem superfluous and almost antithetical to what it was in 1.5.

Why is it nice?

I can see some value to Lua; it allows for more complex routing rules in a way that's comfortable for a programmer. (This is pretty much what I use Lua for in nginx, too.)

Mail, though--yeah, nope.

Great!

But no http2 so it won't get in front of my nginx instances, yet ;)

It's too late to include new draft HTTP/2 in 1.6, so it'll be in 1.7

I was comparing HAproxy to Squid a while ago and could not figure out what's haproxy's advantage over squid? I ended up using Squid but still am very interested in HAproxy, would like to learn more about it.

Squid remains to be the only one that can deal with SSL proxying(yes it's kind of MITM, but it's needed sometimes), and it's also the real "pure" open source. HAproxy might be better fit for enterprises that need support?

HAProxy is a TCP/HTTP load balancer, so the entire perspective of the software (from configuration to feature emphasis) stems from that.

Squid is a caching HTTP proxy, which began with forward proxying but also supports reverse proxying. I wouldn't regard it as relevant to modern, dynamic architectures as HAProxy or Varnish (another caching-focused project).

There's no real difference in open source purity between any of these projects, unless you dislike the stewardship of a company. HAProxy has existed for a long time without such stewardship (as has Varnish). Indeed, Squid's lack of commercial backing might be a hint as to its current relevance.

Varnish is a good HTTP caching server, but with the rise of HTTPS and soon HTTP/2 I'm not sure it'll change since last time I heard its developers don't intend to support TLS at all.

Still true, but you can use HAProxy (or Pound, or...) to terminate TLS, and pass the TCP connection through to Varnish 4.1 using the PROXY protocol (so you get the client IP).

Good read about Varnish and SSL(again). https://www.varnish-cache.org/docs/trunk/phk/ssl_again.html

I disagree, Poul-Henning Kamp's HTTPS/HTTP2 rant is well known, but he's not going to abandon the project. He has steered it to follow the unix ideals of doing one thing well. They (varnish) forked stud and bought it up to date as hitch [1] which covers TLS. At some point they will incorporate HTTP2 once the demand is there.

https://github.com/varnish/hitch

Poul-Henning Kamp's HTTPS/HTTP2 rant ->https://queue.acm.org/detail.cfm?id=2716278

"pure" opensource doesn't exist: There is open source and there is closed source. HAProxy is open source, products developed by HAProxy Technologies are also open source for our customers!!!

on the other side, you have varnish plus and nginx plus which are closed source, which means their clients can't have access to the source code, they don't know what they run.

Just so you know, you don't need to sign your comments (with Baptiste). You may wish to review the guidelines on commenting here:

https://news.ycombinator.com/newsguidelines.html

"Please don't sign comments; they're already signed with your username. If other users want to learn more about you, they can click on it to see your profile."

Lots of goodness!

Supports Lua? SWEET!

Reply on news.ycombinator.com