Le 18/01/2019 à 14:23, Luke Seelenbinder a écrit :
Quick clarification on the previous message.
The code emitting the warning is almost assuredly here:
https://github.com/haproxy/haproxy/blob/ed7a066b454f09fee07a9ffe480407884496461b/src/proto_htx.c#L3242
not in proto_http.c, seeing how this is in htx mode not http mode.
I've traced the issue to likely being caused by the following condition false:
https://github.com/haproxy/haproxy/blob/202c6ce1a27c92d21995ee82c71b2f70c636e3ea/src/htx.c#L93
We are dealing with a lot of larger responses (PNGs, 50-100KB/request on avg)
with perhaps 10 simultaneous initial requests on the same h2 connection being
very common. That sounds like I may in fact need to tweak some buffer settings
somewhere. In http/1.1 mode, these requests were spread out across four
connections with browsers blocking until the previous connection finished.
The documentation is only somewhat helpful for tune.bufsize and
tune.maxrewrite, http/2 and large requests. If this isn't a bug, would someone
be willing to offer some guidance into good values for these buffer sizes?
Thanks for your help!
Hi Luke,
I'm able to reproduce the bug. The H2/HTX multiplexer is not aware of
the buffer reserve. So tweaking tune.maxrewrite won't have any effect.
I'll work on a fix.
Thanks,
--
Christopher Faulet
