On Sun, Sep 27, 2015 at 05:05:14PM +0200, Aleksandar Lazic wrote:
> >Default settings :
> > maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents =
> >200
>
> You see here the bufsize ^^^^^^^ is 16K which displays BUFSIZE at build
> time not the tune.bufsize(global.tune.bufsize).
> Maybe this should be changed or modified?
>
> This output is from
> http://git.haproxy.org/?p=haproxy-1.5.git;a=blob;f=src/haproxy.c#l240
> http://git.haproxy.org/?p=haproxy-1.5.git;a=blob;f=include/common/defaults.h#l26
Yes and MAXREWRITE is assigned just at the line below.
BTW, I never use it at half the buffer size, this choice dates from the early
days where we were running with 4kB buffers and 2kB sounded good for rewrites.
But now with 16kB, we don't need 8kB rewrites.
The assignment to bufsize/2 is not exact in fact. What is really done is
that it's pre-initialized to MAXREWRITE = BUFSIZE/2 (compile-time BUFSIZE),
and is only reassigned to bufsize/2 if it is larger, in order to leave some
room for message processing. This means that if you increase tune.bufsize
beyond BUFSIZE, tune.maxrewrite is not readjusted. See haproxy.c here :
1020
1021 if (global.tune.maxrewrite >= global.tune.bufsize / 2)
1022 global.tune.maxrewrite = global.tune.bufsize / 2;
1023
I personally think that this choice is completely outdated and counter-
productive. I'd be willing to proceed like this :
- preinitialize maxrewrite to min(1024, bufsize/2)
- let the user override it using tune.maxrewrite
- if the final value is too large for the buffer, fix it as above and
emit a warning.
This will maintain compatibility with existing setups and will significantly
reduce the margin, hence increase the ability to process large messages.
I can do this before issuing dev6 today if nobody objects.
Willy
