Re: [ANNOUNCE] haproxy-1.9.0
Hi Willy.
Am 20-12-2018 10:29, schrieb Willy Tarreau:
On Thu, Dec 20, 2018 at 09:17:00AM +0100, Aleksandar Lazic wrote:
Runtime API Improvements: It would be nice when you add a block that
hanging or
dead processes can also be debugged with this API now. Maybe I have
overseen it.
It is already the case. It's not shown on the article, but the main
benefit
that comes from this mechanism is that you have the list of current and
old
processes, and that you can access them all. It is something I've been
missing for a long time, to have a CLI connection to an old process
that
does not want to die, to see what's happening.
Yep. Exactly that info would be nice to have in the article.
It's a USP (unique selling proposition) IMHO ;-)
Server Queue Priority Control: It would be nice to have a example for
server
decision based on Server Queue Priority.
It's not a server decision, it's a dequeuing decision. To give you a
concrete
example of what I'm using on my build farm, I'm using haproxy to
load-balance
distcc traffic to a bunch of build nodes. Some files are large and slow
to
compile, others are small and build fast. The time it takes to build
the
largest file can be almost as long as the total build time. If these
files
start to build after the other ones, the total build time increases
because
I have to wait for such a large file to be built on one node at the
end. So
instead what I'm doing is that I sort the queue by file size. Each time
a
connection slot is available on a server, instead of picking the oldest
entry, haproxy picks the one with the largest file. This way large
files
start to build before small ones and the build completes much faster.
But there is a caveat to doing this : if you have a very large number
of
large files, you can leave small files starving in the queue till the
timeout strikes. That's what happened to me when building my kernels.
So
I changed from set-priority-class to set-priority-offset to address
this.
Now large files are built up to 10 seconds earlier and small files are
built up to 10 seconds later. By doing this I can respect both the size
ordering and bound the distance between the extremes, and I don't have
a timeout anymore.
As always well explained thanks.
This is what my config looks like (with the old set-priority-class
still present but commented out), I'm copy-pasting it here because I
think it's self-explanatory :
Cool thanks.
# wait for the payload to arrive before connecting to the
server
tcp-request inspect-delay 1m
tcp-request content reject unless { distcc_param(DOTI) -m found
}
# convert kilobytes to classes (negated)
# test: tcp-request content set-var(sess.size) str(2b95)
tcp-request content set-var(sess.size) distcc_param(DOTI)
tcp-request content set-var(sess.prio)
var(sess.size),div(-1024),add(2047)
tcp-request content set-var(sess.prio) int(0) if {
var(sess.prio) -m int lt 0 }
tcp-request content set-var(sess.prio) int(2047) if {
var(sess.prio) -m int gt 2047 }
#tcp-request content set-priority-class var(sess.prio)
# offset up to +10 seconds for small files
tcp-request content set-priority-offset var(sess.prio),mul(5)
balance leastconn
default-server on-marked-down shutdown-sessions
# mcbin: 4xA72: their 4 CPUs must be used before any of the
miqi
server lg1192.168.0.201:3632 check weight 5 maxconn 4
server lg2192.168.0.202:3632 check weight 5 maxconn 4
server lg3192.168.0.203:3632 check weight 5 maxconn 4
server lg4192.168.0.204:3632 check weight 5 maxconn 4
server lg5192.168.0.205:3632 check weight 5 maxconn 4
server lg6192.168.0.206:3632 check weight 5 maxconn 4
server lg7192.168.0.207:3632 check weight 5 maxconn 4
# miqi: 4xA17
server miqi-1 192.168.0.225:3632 check weight 1 maxconn 4
server miqi-2 192.168.0.226:3632 check weight 1 maxconn 4
server miqi-3 192.168.0.227:3632 check weight 1 maxconn 4
server miqi-4 192.168.0.228:3632 check weight 1 maxconn 4
server miqi-5 192.168.0.229:3632 check weight 1 maxconn 4
server miqi-6 192.168.0.230:3632 check weight 1 maxconn 4
server miqi-7 192.168.0.231:3632 check weight 1 maxconn 4
server miqi-8 192.168.0.232:3632 check weight 1 maxconn 4
server miqi-9 192.168.0.233:3632 check weight 1 maxconn 4
server miqi-a 192.168.0.234:3632 check weight 1 maxconn 4
Willy
Regards
Aleks
Re: [ANNOUNCE] haproxy-1.9.0
On Thu, Dec 20, 2018 at 09:17:00AM +0100, Aleksandar Lazic wrote:
> Runtime API Improvements: It would be nice when you add a block that hanging
> or
> dead processes can also be debugged with this API now. Maybe I have overseen
> it.
It is already the case. It's not shown on the article, but the main benefit
that comes from this mechanism is that you have the list of current and old
processes, and that you can access them all. It is something I've been
missing for a long time, to have a CLI connection to an old process that
does not want to die, to see what's happening.
> Server Queue Priority Control: It would be nice to have a example for server
> decision based on Server Queue Priority.
It's not a server decision, it's a dequeuing decision. To give you a concrete
example of what I'm using on my build farm, I'm using haproxy to load-balance
distcc traffic to a bunch of build nodes. Some files are large and slow to
compile, others are small and build fast. The time it takes to build the
largest file can be almost as long as the total build time. If these files
start to build after the other ones, the total build time increases because
I have to wait for such a large file to be built on one node at the end. So
instead what I'm doing is that I sort the queue by file size. Each time a
connection slot is available on a server, instead of picking the oldest
entry, haproxy picks the one with the largest file. This way large files
start to build before small ones and the build completes much faster.
But there is a caveat to doing this : if you have a very large number of
large files, you can leave small files starving in the queue till the
timeout strikes. That's what happened to me when building my kernels. So
I changed from set-priority-class to set-priority-offset to address this.
Now large files are built up to 10 seconds earlier and small files are
built up to 10 seconds later. By doing this I can respect both the size
ordering and bound the distance between the extremes, and I don't have
a timeout anymore.
This is what my config looks like (with the old set-priority-class
still present but commented out), I'm copy-pasting it here because I
think it's self-explanatory :
# wait for the payload to arrive before connecting to the server
tcp-request inspect-delay 1m
tcp-request content reject unless { distcc_param(DOTI) -m found }
# convert kilobytes to classes (negated)
# test: tcp-request content set-var(sess.size) str(2b95)
tcp-request content set-var(sess.size) distcc_param(DOTI)
tcp-request content set-var(sess.prio)
var(sess.size),div(-1024),add(2047)
tcp-request content set-var(sess.prio) int(0) if { var(sess.prio) -m
int lt 0 }
tcp-request content set-var(sess.prio) int(2047) if { var(sess.prio)
-m int gt 2047 }
#tcp-request content set-priority-class var(sess.prio)
# offset up to +10 seconds for small files
tcp-request content set-priority-offset var(sess.prio),mul(5)
balance leastconn
default-server on-marked-down shutdown-sessions
# mcbin: 4xA72: their 4 CPUs must be used before any of the miqi
server lg1192.168.0.201:3632 check weight 5 maxconn 4
server lg2192.168.0.202:3632 check weight 5 maxconn 4
server lg3192.168.0.203:3632 check weight 5 maxconn 4
server lg4192.168.0.204:3632 check weight 5 maxconn 4
server lg5192.168.0.205:3632 check weight 5 maxconn 4
server lg6192.168.0.206:3632 check weight 5 maxconn 4
server lg7192.168.0.207:3632 check weight 5 maxconn 4
# miqi: 4xA17
server miqi-1 192.168.0.225:3632 check weight 1 maxconn 4
server miqi-2 192.168.0.226:3632 check weight 1 maxconn 4
server miqi-3 192.168.0.227:3632 check weight 1 maxconn 4
server miqi-4 192.168.0.228:3632 check weight 1 maxconn 4
server miqi-5 192.168.0.229:3632 check weight 1 maxconn 4
server miqi-6 192.168.0.230:3632 check weight 1 maxconn 4
server miqi-7 192.168.0.231:3632 check weight 1 maxconn 4
server miqi-8 192.168.0.232:3632 check weight 1 maxconn 4
server miqi-9 192.168.0.233:3632 check weight 1 maxconn 4
server miqi-a 192.168.0.234:3632 check weight 1 maxconn 4
Willy
Re: [ANNOUNCE] haproxy-1.9.0
Am 20.12.2018 um 06:48 schrieb Willy Tarreau: > On Wed, Dec 19, 2018 at 11:31:33PM +0100, Aleksandar Lazic wrote: >>> Well, I know that so quick a summary doesn't do justice to the developers >>> having done all this amazing work, but I've seen that some of my coworkers >>> have started to write an article detailing all these new features, so I >>> won't waste my time paraphrasing them. I'll pass the URL here once this >>> article becomes public. No, I'm not lazy, I'm tired and hungry ;-) > > And here comes the link, it's more detailed than above : > > https://www.haproxy.com/blog/haproxy-1-9-has-arrived/ good written ;-). 2 suggestions. Runtime API Improvements: It would be nice when you add a block that hanging or dead processes can also be debugged with this API now. Maybe I have overseen it. Server Queue Priority Control: It would be nice to have a example for server decision based on Server Queue Priority. > I still have to catch up with a large number of unresponded e-mails, and > once done, I'll send another update explaining how I hope we can organizer > our work better for the next steps. > >> Amazing work to the whole team. >> >> Take a good food, it's easy in France ;-), and a deep sleep to recharge your >> batteries, you and your team have more the deserve it. > > Thanks Aleks, now both done. Very good cassoulet less than 2km away from > the office ;-) ;-) > Cheers, > Willy Regards Aleks
Re: [ANNOUNCE] haproxy-1.9.0
On Wed, Dec 19, 2018 at 11:31:33PM +0100, Aleksandar Lazic wrote: > > Well, I know that so quick a summary doesn't do justice to the developers > > having done all this amazing work, but I've seen that some of my coworkers > > have started to write an article detailing all these new features, so I > > won't waste my time paraphrasing them. I'll pass the URL here once this > > article becomes public. No, I'm not lazy, I'm tired and hungry ;-) And here comes the link, it's more detailed than above : https://www.haproxy.com/blog/haproxy-1-9-has-arrived/ I still have to catch up with a large number of unresponded e-mails, and once done, I'll send another update explaining how I hope we can organizer our work better for the next steps. > Amazing work to the whole team. > > Take a good food, it's easy in France ;-), and a deep sleep to recharge your > batteries, you and your team have more the deserve it. Thanks Aleks, now both done. Very good cassoulet less than 2km away from the office ;-) Cheers, Willy
Re: [ANNOUNCE] haproxy-1.9.0
Hi.
Am 19.12.2018 um 19:33 schrieb Willy Tarreau:
> Hi,
>
> HAProxy 1.9.0 was released on 2018/12/19. It added 45 new commits
> after version 1.9-dev11.
>
> We still had a number of small issues causing the various artefacts that
> have been visible on haproxy.org since this week-end, but now everything
> looks OK. So it's better to release before we discover new issues :-)
Good Idea ;-)
The image is available.
###
docker run --rm --entrypoint /usr/local/sbin/haproxy me2digital/haproxy19 -vv
HA-Proxy version 1.9.0 2018/12/19 - https://haproxy.org/
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits
OPTIONS = USE_LINUX_SPLICE=1 USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1
USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.1.1a 20 Nov 2018
Running on OpenSSL version : OpenSSL 1.1.1a 20 Nov 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
h2 : mode=HTXside=FE|BE
h2 : mode=HTTP side=FE
: mode=HTXside=FE|BE
: mode=TCP|HTTP side=FE|BE
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace
###
> Speaking more seriously, in the end, what we expected to be just a technical
> release looks pretty nice on the features perspective. The features by
> themselves are not high-level but address a wide number of integration
> cases that overall make this version really appealing.
>
> In the end 1.9 brings to end users (as a quick summary) :
> - end-to-end HTTP/2
> - advanced master process management with its own CLI
> - much more scalable multi-threading
> - regression test suite
> - priority-based dequeueing
> - better cache supporting larger objects
> - early hints (HTTP 103)
> - cipher suites for TLS 1.3
> - random balance algorithm
> - fine-grained timers for better observability
> - stdout logging for containers and systemd
>
> And the rest which has kept us very busy was needed to achieve this and
> to pave the way to future developments and more contributions from people
> who won't have to know the internals as deeply as it used to be needed.
> It's expected that the road to 2.0 will be calmer now.
>
> Well, I know that so quick a summary doesn't do justice to the developers
> having done all this amazing work, but I've seen that some of my coworkers
> have started to write an article detailing all these new features, so I
> won't waste my time paraphrasing them. I'll pass the URL here once this
> article becomes public. No, I'm not lazy, I'm tired and hungry ;-)
Amazing work to the whole team.
Take a good food, it's easy in France ;-), and a deep sleep to recharge your
batteries, you and your team have more the deserve it.
> Please find the usual URLs below :
>Site index : http://www.haproxy.org/
>Discourse: http://discourse.haproxy.org/
>Slack channel: https://slack.haproxy.org/
>Sources : http://www.haproxy.org/download/1.9/src/
>Git repository : http://git.haproxy.org/git/haproxy-1.9.git/
>Git Web browsing : http://git.haproxy.org/?p=haproxy-1.9.git
>Changelog: http://www.haproxy.org/download/1.9/src/CHANGELOG
>Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/
>
> Willy
Very best regards
aleks
> ---
> Complete changelog :
> Christopher Faulet (7):
> BUG/MEDIUM: compression: Use the right buffer pointers to compress
> input data
> BUG/MINOR: mux_pt: Set CS_FL_WANT_ROOM when count is zero in rcv_buf()
> callback
> BUG/MEDIUM: stream: Forward the right amount of data before infinite
> forwarding
> BUG/MINOR: proto_htx: Call the HTX version of the function managing
> client
