You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
reduce the number of epoll_ctl() calls and slightly improve performance in
9442
9444
certain scenarios. This is still experimental, it may result in frozen
9443
9445
connections if bugs are still present, and is disabled by default.
9446
+
</pre><a class="anchor" name="tune.glitches.kill.cpu-usage"></a><a class="anchor" name="3-tune.glitches.kill.cpu-usage"></a><a class="anchor" name="3.2-tune.glitches.kill.cpu-usage"></a><a class="anchor" name="tune.glitches.kill.cpu-usage (Global section)"></a><a class="anchor" name="tune.glitches.kill.cpu-usage (Performance tuning)"></a><div class="keyword"><b><a class="anchor" name="tune.glitches.kill.cpu-usage"></a><a href="#3.2-tune.glitches.kill.cpu-usage">tune.glitches.kill.cpu-usage</a></b> <span style="color: #080"><number></span></div><pre class="text">Sets the minimum CPU usage between 0 and 100, at which connections showing
9447
+
too many glitches will be killed. This applies to connections that have
9448
+
reached their glitches-threshold limit. In environments where very long
9449
+
connections often behave badly without causing any performance impact, it
9450
+
might be desirable to keep them regardless of their misbehavior as long as
9451
+
they do not hurt, and to only start to kill such connections when the CPU is
9452
+
getting busy. This parameters allows to specify that a connection reaching
9453
+
its glitches threshold will be actively killed when the CPU usage is at this
9454
+
level or above, but never when it's below. Note that the CPU usage is
9455
+
measured per thread, so a single misbehaving connection might be killed. The
9456
+
default is zero, meaning that a connection reaching its glitches-threshold
9457
+
will automatically get killed. A rule of thumb would be to set this value to
9458
+
twice the usually observed CPU usage, or the commonly observed CPU usage plus
9459
+
half the idle one (i.e. if CPU commonly reaches 60%, setting 80 here can make
9460
+
sense). This parameter has no effect without tune.h2.fe.glitches-threshold or
9461
+
tune.quic.frontend.glitches-threshold. See also the global parameters
9462
+
"<a href="#tune.h2.fe.glitches-threshold">tune.h2.fe.glitches-threshold</a>" and "<a href="#tune.quic.frontend.glitches-threshold">tune.quic.frontend.glitches-threshold</a>".
9444
9463
</pre><a class="anchor" name="tune.h1.zero-copy-fwd-recv"></a><a class="anchor" name="3-tune.h1.zero-copy-fwd-recv"></a><a class="anchor" name="3.2-tune.h1.zero-copy-fwd-recv"></a><a class="anchor" name="tune.h1.zero-copy-fwd-recv (Global section)"></a><a class="anchor" name="tune.h1.zero-copy-fwd-recv (Performance tuning)"></a><div class="keyword"><b><a class="anchor" name="tune.h1.zero-copy-fwd-recv"></a><a href="#3.2-tune.h1.zero-copy-fwd-recv">tune.h1.zero-copy-fwd-recv</a></b> <span style="color: #800">{ on | off }</span></div><pre class="text">Enables ('on') of disabled ('off') the zero-copy receives of data for the H1
<a class="anchor" name="tune.quic.frontend.max-data-size"></a><a class="anchor" name="3-tune.quic.frontend.max-data-size"></a><a class="anchor" name="3.2-tune.quic.frontend.max-data-size"></a><a class="anchor" name="tune.quic.frontend.max-data-size (Global section)"></a><a class="anchor" name="tune.quic.frontend.max-data-size (Performance tuning)"></a><div class="keyword"><b><a class="anchor" name="tune.quic.frontend.max-data-size"></a><a href="#3.2-tune.quic.frontend.max-data-size">tune.quic.frontend.max-data-size</a></b> <span style="color: #080"><size></span></div><pre class="text">This setting is the hard limit for the number of data bytes in flight over a
9983
10008
QUIC frontend connection. It is reused as the value for the initial_max_data
9984
10009
transport parameter. It directly impacts the upload bandwidth for the peer
0 commit comments