Hi Christopher, I can confirm the patches fixed the issue. Thanks again for fixing this up!
Best, Luke — Luke Seelenbinder Stadia Maps | Founder stadiamaps.com ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, January 21, 2019 2:07 PM, Christopher Faulet <cfau...@haproxy.com> wrote: > 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! > > Best, > > Luke > > Hi Luke, > > Could you try following patches please ? > > Thanks, > > -------------------------------------------------------------- > > Christopher Faulet
publickey - luke.seelenbinder@stadiamaps.com - 0xB23C1E8A.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
