Hi David,
On Wed, Oct 30, 2019 at 08:46:20PM -0400, David Birdsong wrote:
> Hi, I'm trying to figure out whether the following tuneables apply only to
> bound HTTP sockets ou
Thanks for pointing out that the doc is imprecise about these :-)
> tune.h2.header-table-size
We only use a dynamic table on receipt, not for sending, so this setting is
only used:
- on frontend side to receive requests from clients
- on backend side to receive response from servers
There really should be no reason to change it from the defaults quite
honestly, you should really not expect significant gains unless you're
dealing with a very specific application with lots of exchanges of
very repetitive headers not fitting in the default size :-/
> tune.h2.initial-window-size
This one is used on both sides. It advertises the per-stream window
size. On a local network (100 microseconds), the default value of
64k-1 will roughly allow you to handle 5 Gbps per stream. One good
reason to increase it is to favor more filled DATA frames so that
the server gets window updates before its window gets depleted. It
can make sense on video servers for example. For clients the default
value will grant roughly 5 Mbps of upload bandwidth at 100ms latency,
which might not be enough for sites supporting video uploads from
high bandwidth clients.
> tune.h2.max-concurrent-streams
It's used on both sides as well. In my opinion there's no value
in changing it from the default value, because :
- on the frontend side, the client will not be able to use it before
a first round trip to the gains may be really marginal ;
- on the backend side, this would allow haproxy to pack more than
100 streams into a single server connection, which could increase
congestion and the effect of head-of-line blocking, especially
when streams from different front connections get multiplexed
and some are not read fast enough.
Hoping this helps,
Willy
