Live data from Hacker News

What’s new in HAProxy 1.6

blog.haproxy.com

41–42 of 42 posts

Re: What’s new in HAProxy 1.6

#41
post #40

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 compa…

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.

Re: What’s new in HAProxy 1.6

#42

Earlier quoted context omitted.

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 ru…

> (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/c…

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

Post reply on HN