Configuration Manual
-version 3.1-dev9-21
+version 3.1-dev9-50
2024/10/03
@@ -8608,7 +8612,8 @@
3.2.<
not set, the common default value set by tune.h2.initial-window-size applies.
It can make sense to slightly increase this value to allow faster downloads
or to reduce CPU usage on the servers, at the expense of creating unfairness
-between clients. It doesn't affect resource usage.
+between clients. It is better to use tune.h2.be.rxbuf instead, which does not
+cause any unfairness. It doesn't affect resource usage.
See also: tune.h2.initial-window-size.
Sets the HTTP/2 maximum number of concurrent streams per outgoing connection
(i.e. the number of outstanding requests on a single connection to a server).
@@ -8622,7 +8627,20 @@ 3.2.<
clients sharing a connection (keep tune.h2.be.initial-window-size low in this
case). It is highly recommended not to increase this value; some might find
it optimal to run at low values (1..5 typically).
-
Sets the threshold for the number of glitches on a frontend connection, where
+
Sets the HTTP/2 receive buffer size for outgoing connections, in bytes. This
+size will be rounded up to the next multiple of tune.bufsize and will be
+shared between all streams uploading data (both HEADERS and DATA frames). In
+any case, one buffer will always be granted to each stream, and 7/8 of the
+unused buffers will be shared between streams downloading payload, allowing
+to significantly improve upload performance and avoid head-of-line blocking
+(HoL) on backend connections shared between multiple clients when http-reuse
+is set to "always". The advertised per-stream window is automatically
+adjusted to reflect the available space so that in practice it should not be
+required to touch tune.h2.be.initial-window-size. If less than the size
+required to deal with all streams is set, this minimum will be used. The
+default value is about 1600k (100 streams with 16kB buffers each).
+
See also: tune.h2.be.initial-window-size, tune.h2.fe.rxbuf, http-reuse.
+Sets the threshold for the number of glitches on a frontend connection, where
that connection will automatically be killed. This allows to automatically
kill misbehaving connections without having to write explicit rules for them.
The default value is zero, indicating that no threshold is set so that no
@@ -8636,11 +8654,12 @@ 3.2.<
from HAProxy. This setting only affects payload contents (i.e. the body of
POST requests), not headers. When not set, the common default value set by
tune.h2.initial-window-size applies. It can make sense to increase this value
-to allow faster uploads. The default value of 65536 allows up to 5 Mbps of
-bandwidth per client over a 100 ms ping time, and 500 Mbps for 1 ms ping
-time. It doesn't affect resource usage. Using too large values may cause
-clients to experience a lack of responsiveness if pages are accessed in
-parallel to large uploads.
+to allow faster uploads. The default value equals tune.bufsize (16384) and
+allows at least 1.25 Mbps of bandwidth per stream over a 100 ms ping time,
+and 125 Mbps for 1 ms ping time. It doesn't affect resource usage. Using too
+large values may cause clients to experience a lack of responsiveness if
+pages are accessed in parallel to large uploads. It is better to use
+tune.h2.fe.rxbuf instead, which does not cause any unfairness.
See also: tune.h2.initial-window-size.
Sets the HTTP/2 maximum number of concurrent streams per incoming connection
(i.e. the number of outstanding requests on a single connection from a
@@ -8683,7 +8702,19 @@ 3.2.<
note that some load testing tools do not support reconnections and may report
errors with this setting; as such it may be needed to disable it when running
performance benchmarks. See also "tune.h2.fe.max-concurrent-streams".
-
Sets the HTTP/2 dynamic header table size. It defaults to 4096 bytes and
+
Sets the HTTP/2 receive buffer size for incoming connections, in bytes. This
+size will be rounded up to the next multiple of tune.bufsize and will be
+shared between all streams uploading data (both HEADERS and DATA frames). In
+any case, one buffer will always be granted to each stream, and 7/8 of the
+unused buffers will be shared between streams uploading payload, allowing to
+significantly improve upload performance. The advertised per-stream window is
+automatically adjusted to reflect the available space so that in practice it
+should not be required to touch tune.h2.fe.initial-window-size. If less than
+the size required to deal with all streams is set, this minimum will be used.
+The default value of 1600k (100 streams with 16kB buffers each) permits
+roughly 130 Mbps of upload speed for a client with a 100ms RTT.
+
See also: tune.h2.fe.initial-window-size and tune.h2.be.rxbuf.
+Sets the HTTP/2 dynamic header table size. It defaults to 4096 bytes and
cannot be larger than 65536 bytes. A larger value may help certain clients
send more compact requests, depending on their capabilities. This amount of
memory is consumed for each HTTP/2 connection. It is recommended not to
@@ -8691,12 +8722,17 @@ 3.2.<
Sets the default value for the HTTP/2 initial window size, on both incoming
and outgoing connections. This value is used for incoming connections when
tune.h2.fe.initial-window-size is not set, and by outgoing connections when
-tune.h2.be.initial-window-size is not set. The default value is 65536, which
-for uploads roughly allows up to 5 Mbps of bandwidth per client over a
-network showing a 100 ms ping time, or 500 Mbps over a 1-ms local network.
-Given that changing the default value will both increase upload speeds and
-cause more unfairness between clients on downloads, it is recommended to
-instead use the side-specific settings tune.h2.fe.initial-window-size and
+tune.h2.be.initial-window-size is not set. This setting is used both as the
+initial value and as a minimum per stream. The default value equals 16384
+(tune.bufsize), which for uploads roughly allows at least 1.25 Mbps of
+bandwidth per stream over a network showing a 100 ms ping time, or 125 Mbps
+over a 1-ms local network. When less receive buffers than the maximum are in
+use, within the limits defined by tune.h2.be.rxbuf and tune.h2.fe.rxbuf,
+unused buffers will be shared between receiving streams. As such there is
+normally no point in changing this default setting. Given that changing this
+default value will both increase upload speeds and cause more unfairness
+between clients on downloads, it is recommended to instead use the side-
+specific settings tune.h2.fe.initial-window-size and
tune.h2.be.initial-window-size.
Sets the default HTTP/2 maximum number of concurrent streams per connection
(i.e. the number of outstanding requests on a single connection). This value
@@ -31119,7 +31155,7 @@ 11
- HAProxy 3.1-dev9-21 – Configuration Manual
+ HAProxy 3.1-dev9-50 – Configuration Manual
, 2024/10/03
3.2.< clients sharing a connection (keep tune.h2.be.initial-window-size low in this case). It is highly recommended not to increase this value; some might find it optimal to run at low values (1..5 typically). -
3.2.< from HAProxy. This setting only affects payload contents (i.e. the body of POST requests), not headers. When not set, the common default value set by tune.h2.initial-window-size applies. It can make sense to increase this value -to allow faster uploads. The default value of 65536 allows up to 5 Mbps of -bandwidth per client over a 100 ms ping time, and 500 Mbps for 1 ms ping -time. It doesn't affect resource usage. Using too large values may cause -clients to experience a lack of responsiveness if pages are accessed in -parallel to large uploads. +to allow faster uploads. The default value equals tune.bufsize (16384) and +allows at least 1.25 Mbps of bandwidth per stream over a 100 ms ping time, +and 125 Mbps for 1 ms ping time. It doesn't affect resource usage. Using too +large values may cause clients to experience a lack of responsiveness if +pages are accessed in parallel to large uploads. It is better to use +tune.h2.fe.rxbuf instead, which does not cause any unfairness.
3.2.< note that some load testing tools do not support reconnections and may report errors with this setting; as such it may be needed to disable it when running performance benchmarks. See also "tune.h2.fe.max-concurrent-streams". -
3.2.<
11
- HAProxy 3.1-dev9-21 – Configuration Manual
+ HAProxy 3.1-dev9-50 – Configuration Manual
, 2024/10/03
+ HAProxy 3.1-dev9-50 – Configuration Manual
, 2024/10/03