
What’s new in HAProxy 1.6 - oldmantaiter
http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/
======
radoslawc
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.

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

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

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

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

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

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

------
wheaties
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?

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

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

------
nailer
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!

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

~~~
pmahoney
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.)

~~~
merlincorey
> (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...](https://www.freebsd.org/cgi/man.cgi?query=daemon&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html)

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

~~~
pmahoney
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](http://man.cx/start-stop-
daemon%288%29)

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

~~~
yc1010
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

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

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

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

------
binaryanomaly
Great!

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

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

------
ausjke
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?

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

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

~~~
poooogles
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](https://github.com/varnish/hitch)

~~~
ZoF
Poul-Henning Kamp's HTTPS/HTTP2 rant
->[https://queue.acm.org/detail.cfm?id=2716278](https://queue.acm.org/detail.cfm?id=2716278)

------
ErikRogneby
Lots of goodness!

------
wpblogheader
Supports Lua? SWEET!

