Repository navigation
dns: give each waiter of a shared query its own result #44649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
robobun
wants to merge
2
commits into
main
Choose a base branch
from
robobun/e5070f23/dns-own-answer-per-waiter
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 (optional) Any process that opens many connections to one host at once now stalls its event loop for the whole burst, where the base settled the burst in one conversion. Every chained waiter runs addr.to_js_response again inside the single c-ares callback at dns.rs:4343-4345 (same shape at dns.rs:4405, 4465, 4529, 4580), and PendingCacheKey::append puts no cap on the chain. Fix: bound the per-callback work for a shared query, e.g. convert once per global and give each later waiter a structural copy (new array and record objects, shared strings), or cap the chain and start a new wire query past it, so a 10,000-waiter burst stays near the base's 4 ms rather than 157 ms.
Why this was flagged
The trigger is N overlapping identical lookups on one resolver: node:net connect, node:http without keep-alive, a pool warm-up or a Bun.ModuleGraph fan-out all route through dns.lookup and chain on one pending-cache slot. On the base the drain converted once per global (old prev_global branch at dns.rs:4331-4342 of the base) and settled all N waiters with that value, so the callback cost was O(records). After the change each waiter's for_waiter closure at dns.rs:4343 and siblings rebuilds the full answer (per PR: 7,566 instructions, 9 mallocs and 5 JS cells per extra 2-address waiter; 157 ms vs 4 ms for 10,000 waiters on 50 records), all inside one c-ares poll callback with no yield. Every other timer, socket and promise on that loop waits for it. The dismissal accepted the author's cost table as a trade-off; the author's own description asks whether to accept it or add a structural copy, which is the remedy.
Verification: Triggering condition: N overlapping identical lookups on one resolver that chain onto one pending-cache slot before the reply arrives.
Outcome::for_waiter(src/runtime/dns_jsc/dns.rs:1884-1895) runsconvert()for every waiter; the base converted once per distinct global.PendingCacheKey::append(dns.rs:1022-1030) only links the node onto the tail; there is no cap on chain length.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the trade-off that the Downsides section puts to the reviewer. The numbers for it are in the Notes. Two points on the framing:
net.connect()to one hostname does chain on one lookup (lookupAndConnectinsrc/js/node/net.tscallsdns.lookup), and each connection now gets its own conversion. That cost is small beside the connects. 500 connections tolocalhostfor each batch, release builds, 6 alternating runs: 61.9 ms on main (59.3 to 64.1) and 63.3 ms here (59.4 to 68.7). The 157 ms case is 10,000 waiters on one 50-record answer.The structural copy stays the follow-up if a maintainer wants the lower cost for each waiter: convert once into a value that no caller receives, then give each waiter a new array and new records with the strings shared.
Outcomestays move-only in that shape too.