7474 </li >
7575 </ul >
7676
77+ <Callout type =" warning" >
78+ <strong >Clarification (updated):</strong > Disabling HTTP/3 (QUIC) on the Caddy edge proxy
79+ was <strong >not</strong > the root-cause fix for the one-core bottleneck. It was an earlier
80+ experiment that had no material impact on the softirq hotspot. The actual remediation was
81+ enabling RPS/RFS packet steering. See the
82+ <a href =" #phase-2-disable-http3" >Phase 2</a > and
83+ <a href =" #phase-3-enable-rps-rfs" >Phase 3</a > sections below for the evidence.
84+ <br /><br />
85+ <strong >Protocol boundary note:</strong > Clients can connect to the edge proxy via HTTP/3
86+ while the proxy communicates with backend services over existing HTTP transport. Backend
87+ native HTTP/3 support is <em >not</em > required to offer HTTP/3 at the edge. Whether to
88+ enable or disable HTTP/3 at the proxy should be treated as a product/operations choice
89+ guided by monitoring, not as a default performance lever.
90+ <br /><br />
91+ See
92+ <a href =" https://github.com/torrust/torrust-tracker-demo/issues/31"
93+ >torrust-tracker-demo#31</a
94+ >
95+ for the rationale on re-enabling edge HTTP/3, and
96+ <a href =" https://github.com/torrust/torrust-tracker/issues/1736" >torrust-tracker#1736</a >
97+ for tracking native HTTP/3 support in the tracker.
98+ </Callout >
99+
77100 <h2 id =" what-problem-we-detected" >What Problem We Detected</h2 >
78101 <p >
79102 The tracker host was under sustained CPU pressure. Standard process-level checks showed
@@ -149,8 +172,13 @@ HTTP1/UDP1 external status: Working`}
149172 />
150173
151174 <p >
152- Conclusion: disabling HTTP/3 was good hygiene, but it did not change the one-core softirq
153- bottleneck.
175+ Conclusion: disabling HTTP/3 did not change the one-core softirq bottleneck. This
176+ experiment confirmed that QUIC packet processing on UDP 443 was not the driver of the
177+ hotspot. Enabling or disabling HTTP/3 at the edge proxy should be treated as a separate
178+ product/operations decision — see the
179+ <a href =" https://github.com/torrust/torrust-tracker-demo/issues/31" >follow-up rationale</a
180+ >
181+ for re-enabling it.
154182 </p >
155183
156184 <h2 id =" phase-3-enable-rps-rfs" >Phase 3: Enable RPS/RFS</h2 >
@@ -274,6 +302,16 @@ HTTP1/UDP1 external status: Working`}
274302 <li >Keep RPS/RFS enabled permanently on the current host.</li >
275303 <li >Close the tuning scope in ISSUE-29 as completed.</li >
276304 <li >Track capacity follow-up separately (scale-up planning in ISSUE-30).</li >
305+ <li >
306+ HTTP/3 at the edge proxy is a separate product/operations decision. See
307+ <a href =" https://github.com/torrust/torrust-tracker-demo/issues/31"
308+ >torrust-tracker-demo#31</a
309+ >
310+ for the rationale on re-enabling it, and
311+ <a href =" https://github.com/torrust/torrust-tracker/issues/1736" >torrust-tracker#1736</a
312+ >
313+ for tracking native HTTP/3 support.
314+ </li >
277315 </ol >
278316 <p >
279317 The practical outcome is clear: packet-path tuning fixed the single-core bottleneck, and
@@ -299,6 +337,17 @@ HTTP1/UDP1 external status: Working`}
299337 >Related post: nf_conntrack overflow incident and fix</a
300338 >
301339 </li >
340+ <li >
341+ <a href =" https://github.com/torrust/torrust-tracker-demo/issues/31"
342+ >torrust-tracker-demo#31 — Re-enable edge HTTP/3 and document rationale</a
343+ >
344+ </li >
345+ <li >
346+ <a href =" https://github.com/torrust/torrust-tracker/issues/1736"
347+ >torrust-tracker#1736 — Document HTTP/3 support via reverse proxy and track native
348+ HTTP/3 follow-up</a
349+ >
350+ </li >
302351 </ul >
303352 </div >
304353 </div >
0 commit comments