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.
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.
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.
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.
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].
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.
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
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.)
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.
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.
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).
"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.
"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."
