On Tue, Aug 25, 2020 at 03:32:21PM +0200, Ionel GARDAIS wrote: > That's improvement ! > > Are there similar settings in haproxy to get these numbers ?
It's difficult to respond, because what the article shows is that by default there was a performance limitation which was essentially due to how buffering works in nginx. It doesn't work the same way in haproxy so the corner cases will be different. Typically in our case the H2 communication with the client is totally independent of the communication with the server, because that's performed at different places. The client will gets its WINDOW_UPDATE as payload is consumed (even incomplete frames). By default we also use the default 64kB stream window size, but this can be changed via tune.h2.initial-window-size. The default buffer size is 16kB but can be increased using bufsize. There's no dynamic buffer sizing, however on the send side we use a ring of buffers (32 by default). This means that in practice we can read one buffer, pass it to the other side and continue to read, which effectively corresponds to having up to 33 times the request buffer even if the server doesn't read as fast. So the model is a bit different but could deserve being compared. In any case we're not changing the buffer size on the fly nor allocating larger buffers for slower clients. Regards, Willy
