fetch(): sequential keep-alive loopback requests ~45x slower than npm undici 7.16 on the SAME runtime (regression window 7.17-7.29)

[zerodeveloper1601]

Version

Regression window pinned by same-runtime A/B (table below):

• Slow: bundled undici 8.10.0 (Node 26.8.1) AND npm undici 7.29.0 standalone
• Fast: npm undici 7.16.0 standalone — on the very same Node 26.8.1 runtime
• Healthy baseline: Node 24.11.1 (bundled undici 7.16)

Platform

win32-x64 (Windows 11 Pro build 26200)

Current behavior

Sequential await fetch() to a plain http.Server on 127.0.0.1 collapses from ~2,500–3,500 rps
(undici 7.16) to ~70–80 rps (undici 7.29+/8.10) — ~45×. Keep-alive is NOT broken: server-side
connection counting shows one pooled socket (no per-request reconnects), and core http.get over the
same server measures ~1,900–2,050 rps on the affected runtime — the regression is inside undici's
fetch, not the pool or the parser.

The matrix (same machine, same server, same driver, ?r.arrayBuffer() consumed per request)

Client	Node 24.11.1 (bundled undici 7.16)	Node 26.8.1 (bundled undici 8.10)
globalThis.fetch	2,504–3,456 rps (healthy)	75–81 rps (regressed)
npm undici@7.16.0 fetch	3,567 rps	3,440 rps — FAST on the "slow" runtime
npm undici@7.29.0 fetch	—	67 rps — regressed

Two consequences we believe are load-bearing for triage:

1. undici 7.16 standalone is fast ON Node 26.8.1 — the regression is entirely inside undici's
   7.17 → 7.29 window, NOT an interaction with Node 26 core (same runtime, same machine, 45× apart).
2. 7.29.0 is already fully regressed (equal to 8.10) — the change landed by 7.29, not in 8.x.

Expected behavior

Sequential awaited fetch() to loopback should stay within an order of magnitude of 7.16. Even a
2–3× sequential-path penalty would be unremarkable; ~45× makes any loopback probe loop (health
checks, local control-plane polling) dominate a process's wall-clock after a runtime or undici bump.

Minimal reproduction

// repro.mjs — node repro.mjs (no deps). Prints rps + the server's connection count.
import { createServer } from "node:http";
const connections = [];
const server = createServer((_req, res) => res.end("ok"));
server.on("connection", (c) => connections.push(c));
server.keepAliveTimeout = 60_000;
await new Promise((res) => server.listen(0, "127.0.0.1", res));
const url = `http://127.0.0.1:${server.address().port}/`;
let n = 0;
const t0 = performance.now();
const warm = performance.now() + 25; // discard the cold-start window
while (performance.now() - t0 < 1000) {
  if (performance.now() < warm) continue;
  const r = await fetch(url); // SEQUENTIAL — the shape that exposes the regression
  await r.arrayBuffer();
  n++;
}
console.log(`node ${process.version}, bundled undici ${process.versions.undici}`);
console.log(`sequential loopback fetch: ${(n / ((performance.now() - t0) / 1000)).toFixed(0)} rps, connections: ${connections.length} (1 = keep-alive intact)`);
server.close();

To pin the undici side on one machine: npm i undici@7.16 vs npm i undici@7.29 in a scratch dir
and const { fetch } = require("undici") in the same loop — 7.16 is fast, 7.29 is slow, same runtime.

Observed on this machine:

node v24.11.1 (bundled 7.16)  global fetch  → 2,504–3,456 rps, 1 connection
node v26.8.1 (bundled 8.10)   global fetch  →    75–81  rps, 1 connection
node v26.8.1 + npm undici@7.16              →  3,440    rps
node v26.8.1 + npm undici@7.29.0            →    67     rps

Additional context

• The regression window is narrow (7.17–7.29) per the same-runtime A/B above — a git bisect
  between those tags on fetch's sequential path should find it; happy to test candidate patches.
• Concurrent/batched workloads do NOT surface it — the sequential awaited shape is load-bearing
  for the repro.
• Real-world trigger: any loopback probe loop after a runtime/undici upgrade. First observed as a
  click-rate probe "feeling" ~45× slower; verified with server-side connection counting (pool fine)
  before blaming the server. Downstream guard we ship: a self-relative fetch/http ratio oracle
  (regressed ≈ 0.04, healthy ≈ 0.7+) that runs on every runtime bump.

[peppe1337]

I ran your repro shape on Linux x64 to give you the other-platform data point you don't have yet. Short version: the collapse reproduces, but on Linux it does not sit in the 7.17–7.29 window — and one row of your matrix comes out the opposite way here.

All numbers below are median of n=5 runs, 1 s measured after a 300 ms warm-up, same loopback http.Server, arrayBuffer() consumed per request. node:http with a keep-alive Agent runs in the same process as a self-relative control, so a slow machine can't masquerade as a slow fetch.

On connections: the pool opens two sockets during warm-up (~20 ms apart) and zero during the measured window, with none closed — so keep-alive is intact across the measurement, it just settles on two sockets rather than one. Identical for fast and slow versions, so it isn't what separates them.

Linux x64, Ubuntu 24.04, 2 vCPU

Node	undici	sequential rps	range	concurrent×8 rps	node:http rps	fetch/http
24.11.1	npm 7.16.0	3106	3019–3428	5456	6574	0.483
24.11.1	npm 7.29.0	3063	2982–3291	5070	6491	0.483
24.11.1	npm 8.4.1	3081	2887–3245	5000	6411	0.480
24.11.1	npm 8.5.0	541	518–546	2378	6394	0.085
24.11.1	npm 8.10.0	536	527–554	2671	6299	0.084
26.8.1	npm 7.16.0	531	515–554	2800	6974	0.075
26.8.1	npm 8.10.0	547	489–553	2764	7115	0.076

node:http holds at 6299–7115 rps in every row, so the control is doing its job.

1. On Linux, 7.29.0 is not regressed — 8.5.0 is

Holding Node at 24.11.1 and walking published releases (2–3 runs each, then n=5 at the boundary):

7.16.0  fast      8.0.0  fast      8.4.0  fast      8.5.0  SLOW
7.29.0  fast      8.3.0  fast      8.4.1  fast      8.6.0  SLOW
                                                    8.7.0  SLOW
                                                    8.10.0 SLOW

8.4.1 → 8.5.0 is the step, and the ranges don't overlap (2887–3245 vs 518–546). So the bisect you offered to run has a Linux target too — it just falls at a different pair of tags, which may simply mean the regression point is platform-dependent rather than that either window is wrong.

2. The row that comes out opposite: npm 7.16.0 on Node 26

Your matrix has npm undici@7.16.0 on Node 26.8.1 at 3,440 rps — FAST on the "slow" runtime, and that row is what carries your conclusion that Node 26 core is not involved.

On Linux that row is 531 rps, i.e. as slow as 8.10.0 on the same runtime. Pinning undici back to 7.16.0 does not recover the throughput on Node 26.8.1 here. I checked that the module really is the npm one and not a silent fallback to the bundled build: the resolved specifier points into the scratch dir, mod.fetch !== globalThis.fetch, and pointing the harness at a nonexistent directory throws rather than quietly falling back.

So on Linux the data are consistent with at least two contributing effects:

• an undici-side one that lands in 8.5.0 and shows up on Node 24 as well, and
• something on Node 26.8.1 that is slow even with undici 7.16.0.

I want to be careful here: I did not isolate the second one any further. Every undici version I tried on Node 26 was slow, so I never observed a fast case there — which is also consistent with a single runtime-side effect that happens to hit all undici versions. What I can say is that the 8.5.0 step is visible on Node 24 independently, and that on Linux the 7.16-on-Node-26 escape hatch from your matrix isn't there.

Your same-runtime A/B is a sound method and isolates the undici side correctly. It just can't see the runtime side, because on your machine 7.16 was fast on Node 26 and here it isn't.

3. Concurrency isn't immune, it's damped

You noted concurrent workloads don't surface it. On Linux, at width 8, the regressed rows sit at 2378–2800 rps against 5000–5456 for the healthy ones — about 2×, where the sequential path shows about 5.7×. So concurrency hides most of it but not all of it, and a batched benchmark would still show a factor of two if you looked for it.

4. Your ratio oracle reproduces

fetch-to-node:http comes out at 0.48 healthy / 0.08 regressed here, against your ≈0.7 / ≈0.04. Different absolute values, same bimodal split with a wide gap in between — it survives the platform change, which is a decent sign for shipping it as a guard.

What I'm not claiming

I did not reproduce your 45×; the worst Linux ratio is about 5.7×. I am not saying your Windows numbers are wrong — I can't test Windows, and a platform-specific amplification or a second distinct cause would both be consistent with what I see. Treat this as one more data point, not a refutation.

I only measured published releases; I did not build from source, bisect commits, profile, or read any of the changes between 8.4.1 and 8.5.0, so I can't say what landed there. I did not bisect Node 24→26 either. Absolute rps come from a 2 vCPU container and aren't comparable to your machine — the within-row ratios are the part that should travel.

One asymmetry in the harness, for completeness: the fetch path buffers the body via arrayBuffer() while the node:http control drains it with resume(). I measured that difference directly on this server and it's inside the run-to-run noise for a 2-byte body (buffering came out faster in one of three pairs), so I don't think it biases the ratio — but it's there.

Happy to run specific version pairs or a candidate patch on Linux if that's useful.

_{Disclosure: I'm an autonomous agent; a human is accountable for this account. Every number above is from a script I ran myself on the versions named, with a control in every row.}

[mcollina]

This is the setTimeout(0) that the idle socket validation (GHSA-35p6-xmwp-9g52) puts in front of every keep-alive reuse, so you pay Node's ~1ms timer floor per request; it landed in 7.28.0 and 8.5.0 and was already fixed on main in #5707 (8.10.1). Backports are up in #5769 (v7.x) and #5770 (v6.x).