http: optimize IncomingMessage._dump

[ronag]

PRE:

┌───────────┬─────────┬─────────┬─────────┬─────────┬──────────┬──────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg      │ Stdev    │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼──────────┼─────────┤
│ Req/Sec   │ 88,319  │ 88,319  │ 95,679  │ 96,447  │ 93,885.1 │ 2,779.85 │ 88,303  │
├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼──────────┼─────────┤
│ Bytes/Sec │ 10.8 MB │ 10.8 MB │ 11.7 MB │ 11.8 MB │ 11.5 MB  │ 339 kB   │ 10.8 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴──────────┴──────────┴─────────┘

POST:

┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 93,823  │ 93,823  │ 100,287 │ 101,119 │ 99,680  │ 1,967.7 │ 93,817  │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 11.5 MB │ 11.5 MB │ 12.2 MB │ 12.3 MB │ 12.2 MB │ 238 kB  │ 11.4 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

[nodejs-github-bot]

Review requested:

• @nodejs/http
• @nodejs/net

[mcollina]

lgtm

[github-actions]

Failed to start CI

   ⚠  Commits were pushed since the last approving review:
   ⚠  - http: optimize IncomingMessage._dump
   ✘  Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/17445334596

[ronag]

I don't know how to deal with the testing of this. Optimally I would like to run all http tests with and without the option.

[ronag]

https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1727/

[ronag]

@RafaelGSS any idea why benchmark ci failed?

[Flarna]

Why should we run all HTTP tests with this option on and off? What makes this option so special to run that a high number of tests?

[ronag]

Why should we run all HTTP tests with this option on and off? What makes this option so special to run that a high number of tests?

I think this is one of those changes that can cause various regression.

[RafaelGSS]

@ronang Benchmark CI https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1728/

You forgot to include the commit SHA.

[ronag]

@RafaelGSS why did you close?

[RafaelGSS]

I was a mistake, sorry @ronag

[lpinca]

I understand that this is behind an option but I find it odd. It breaks the invariant where 'end' / 'close' are always emitted.

[ronag]

This is a valid point. I don't think it's anywhere documented that it must emit the life cycle events. Though it is indeed breaking. It is totally valid from the streams api since you can receive an already closed stream. It will work with stream.finished and stream.pipeline.

[ronag]

@mcollina @RafaelGSS benchmark CI is not meaningful, I added my own autocannon benchmark #59747 (comment)

const http = require('http');

http.createServer((req, res) => {
  res.end();
}).listen(9000);

npx autocannon http://localhost:9000

[mcollina]

Can we implement so that if there is someone watching for ‘end’ or ‘close’, it follows the usual path, while if they are not, we can avoid them?

Alternatively, we could have _dump actually emit them.

[ronag]

With fastify:

nxt-23.0$ npx autocannon http://localhost:9000/
Running 10s test @ http://localhost:9000/
10 connections


┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 0 ms │ 0.03 ms │ 0.84 ms │ 137 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬──────────┬───────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg      │ Stdev     │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼───────────┼─────────┤
│ Req/Sec   │ 23,711  │ 23,711  │ 50,911  │ 79,487  │ 54,421.6 │ 22,087.53 │ 23,701  │
├───────────┼─────────┼─────────┼─────────┼─────────┼──────────┼───────────┼─────────┤
│ Bytes/Sec │ 4.32 MB │ 4.32 MB │ 9.27 MB │ 14.5 MB │ 9.9 MB   │ 4.02 MB   │ 4.31 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴──────────┴───────────┴─────────┘

Req/Bytes counts sampled once per second.
# of samples: 10

544k requests in 10.04s, 99 MB read
nxt-23.0$ npx autocannon http://localhost:9000/
Running 10s test @ http://localhost:9000/
10 connections


┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬───────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max   │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼───────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 0 ms │ 0.01 ms │ 0.27 ms │ 76 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴───────┘
┌───────────┬─────────┬─────────┬────────┬─────────┬─────────┬──────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%    │ 97.5%   │ Avg     │ Stdev    │ Min     │
├───────────┼─────────┼─────────┼────────┼─────────┼─────────┼──────────┼─────────┤
│ Req/Sec   │ 68,287  │ 68,287  │ 82,175 │ 84,223  │ 81,056  │ 4,446.14 │ 68,272  │
├───────────┼─────────┼─────────┼────────┼─────────┼─────────┼──────────┼─────────┤
│ Bytes/Sec │ 12.4 MB │ 12.4 MB │ 15 MB  │ 15.3 MB │ 14.8 MB │ 809 kB   │ 12.4 MB │
└───────────┴─────────┴─────────┴────────┴─────────┴─────────┴──────────┴─────────┘

Req/Bytes counts sampled once per second.
# of samples: 10

811k requests in 10.02s, 148 MB read

[RafaelGSS]

Benchmark result on my tests:

So, tuns out my computer was too fast and it was delivering the same amount of req/sec regardless of binary. In other words, I was being limited by wrk2 itself. Now I have configured proper values and the latency (which is the most important metric in terms of wrk2) has shown the following distribution:

 50.000%  731.00us
 75.000%    1.02ms
 90.000%    1.22ms
 99.000%    1.85ms
 99.900%    2.05ms
 99.990%    2.15ms
 99.999%    2.26ms
100.000%    2.49ms

node v24.5.0

 50.000%  693.00us
 75.000%    0.98ms
 90.000%    1.16ms
 99.000%    1.51ms
 99.900%    1.99ms
 99.990%    2.18ms
 99.999%    2.60ms
100.000%    2.94ms

And autocannon reported:

node v24.5.0

3164k requests in 30.04s, 576 MB read

versus

4007k requests in 30.04s, 729 MB read