Repository navigation
http: significant performance regression on master #37937
Description
Activity
cc @ronag
Reacted by Robert Nagy- addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.httpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.
on Mar 26, 2021 I think that the warning messages originated here: #36816
I think that the warning messages originated here: #36816
I think so as well.
I will take a look as soon as I can
I'm looking into it as well!
I will have time tonight. Please keep me posted if you find anything.
A couple of notes:
#36816 is the cause of the warnings and likely memory leak.
Going to the parent commit has a minor performance benefit:
$ autocannon -c 100 -d 5 -p 10 localhost:3000 Running 5s test @ http://localhost:3000 100 connections with 10 pipelining factor ┌─────────┬──────┬───────┬───────┬───────┬──────────┬─────────┬───────┐ │ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │ ├─────────┼──────┼───────┼───────┼───────┼──────────┼─────────┼───────┤ │ Latency │ 8 ms │ 17 ms │ 19 ms │ 28 ms │ 14.53 ms │ 5.42 ms │ 71 ms │ └─────────┴──────┴───────┴───────┴───────┴──────────┴─────────┴───────┘ ┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐ │ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │ Min │ ├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤ │ Req/Sec │ 60895 │ 60895 │ 68351 │ 68543 │ 66806.4 │ 2971.63 │ 60887 │ ├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤ │ Bytes/Sec │ 11.4 MB │ 11.4 MB │ 12.8 MB │ 12.8 MB │ 12.5 MB │ 556 kB │ 11.4 MB │ └───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘ Req/Bytes counts sampled once per second. 334k requests in 5.03s, 62.5 MB readThe majority performance regression is present in v15 as well, so it's unrelated.
Apparently the majority of the regression happened in the v15 cycle.
v15.0.0: 77k req/sec (median)
v15.11.0: 67k req/sec (median)#36816 is the cause of the warnings and likely memory leak.
I will sort this.
Apparently the majority of the regression happened in the v15 cycle.
v15.0.0: 77k req/sec (median)
v15.11.0: 67k req/sec (median)Are you bisecting?
@mcollina: Any idea how to repro without using autocannon?
I tried:
'use strict'; const common = require('../common'); const http = require('http'); const Countdown = require('../common/countdown'); const NUM_REQ = 128 const agent = new http.Agent({ keepAlive: true }); const countdown = new Countdown(NUM_REQ, () => server.close()); const server = http.createServer(common.mustCall(function(req, res) { res.setHeader('content-type', 'application/json; charset=utf-8') res.end(JSON.stringify({ hello: 'world' })) }, NUM_REQ)).listen(0, function() { for (let i = 0; i < NUM_REQ; ++i) { http.request({ port: server.address().port, agent, method: 'GET' }, function(res) { res.resume(); res.on('end', () => { countdown.dec(); }) }).end(); } }); process.on('warning', common.mustNotCall());
Are you bisecting?
I've done a
nvm"rough" bisect just narrow down a bit my scope of action.I'm doing a
git bisectas we speak, it just takes a lot of time as it spans several V8 versions.Reacted by Robert Nagy@mcollina: Any idea how to repro without using autocannon?
I think you need to use
netto send a manual request with http pipelining.Reacted by Robert Nagy35 remaining items
@mcollina excellent work!
Reacted by Matteo CollinaI've got the fix already identified, I'm just not writing any code today so I will do that first thing Monday morning and have the PR open soon after
Reacted by dnlupDo these things not show up when running a cpu profile? Seems a bit unfortunate that we need to git bisect to identify new or old performance bottlenecks?
Do these things not show up when running a cpu profile? Seems a bit unfortunate that we need to git bisect to identify new or old performance bottlenecks?
They show up. However git bisecting is actually simpler because you do not have to code hypothetical fixes.
The hrtime showed up. It's far down from the main bottleneck, but it was a key difference on an hot path.
Reacted by Robert NagyAnd I did run perf tests on this one change. I just think some of the other issues were masking the perf hit one the hrtime change making it far less obvious. Fortunately, it's a quick fix
Reacted by Matteo Collina- added a commit that references this issue
on Apr 4, 2021 - removedtsc-agendaIssues and PRs to discuss during Technical Steering Committee meetings.Issues and PRs to discuss during Technical Steering Committee meetings.
on Apr 14, 2021 Here is another one: #38245.
I have one more coming :).
#38246 include my last findings.
With the latest PRs having landed, the HTTP throughput of the upcoming v16 is on par with the one of the latest v14. I think this is a milestone and I'll celebrate to close this issue and possibly open a fresh one with other optimizations that we might want to do here.
Reacted by linkgoron, dnlup, Beth Griggs, Théo LUDWIG, Luis Eduardo Brito, Tyler Paul Thompson, Emmanuel Di Iorio and Michael Rotarius
What steps will reproduce the bug?
run:
and then:
on
v14.16this produces:on
master:On master it also produces a significant amount of warnings:
Update as of 2021/3/29 bisect from head a9cdeed: