mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #2613] [Performance] HickoryDNS loses nearly 50% of queries #1030
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#1030
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mokeyish on GitHub (Nov 23, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2613
Describe the bug
I made a simple DNS performance test repository and obtained the most popular 1 million domain names as a test set.
Then it was discovered that HickoryDNS actually lost nearly 50% of the queries.
To Reproduce
https://github.com/mokeyish/dnsperf-testing
Steps to reproduce the behavior:
Case 1: Use nameserver 119.29.29.29 directly
Case 2: use HickoryDNS
.envExpected behavior
Fix this performance issue.
System:
Version:
Crate: server
Version:
github.com/hickory-dns/hickory-dns@001ced84c3@marcus0x62 commented on GitHub (Nov 23, 2024):
Hi @mokeyish,
Running the same git commit as you, this is what I see against 1.1.1.1:
and 8.8.8.8:
Most of the few query failures I did see went away with a longer timeout (I was getting late reply messages in a few cases.)
So, with DNS servers that are reasonably close to me, I can't duplicate the behavior you are seeing. If you can reproduce this readily, trace logs from hickory would be helpful.
@mokeyish commented on GitHub (Nov 23, 2024):
@marcus0x62 Are your two directly testing 1.1.1.1 and 8.8.8.8?
One of my tests is to test 119.29.29.29 directly, and the other is to start HickoryDNS and set the upstream to 119.29.29.29.
@marcus0x62 commented on GitHub (Nov 23, 2024):
No, the output of dnsperf in my previous message shows requests to Hickory, configured to forward to 1.1.1.1 and 8.8.8.8. I used the same forwarding configuration as in your issue report.
@mokeyish commented on GitHub (Nov 23, 2024):
Here are my logs from testing HickoryDNS (left) and dnsperf (right).
@mokeyish commented on GitHub (Nov 23, 2024):
Your data is so close, is it because my computer performance is relatively low? I am running it in WSL.
@mokeyish commented on GitHub (Nov 24, 2024):
@marcus0x62 I ran it on cloudcone and got exactly the same result as yours.
@marcus0x62 commented on GitHub (Nov 24, 2024):
I think I'd need to see the full log output to venture any sort of guess as to what's going on. Trying running your server with:
and attach the full log file.
@mokeyish commented on GitHub (Dec 28, 2024):
@marcus0x62 Hi, Here are some of the logs.
@DirectXMan12 commented on GitHub (Mar 3, 2025):
if this is a performance issue, by doing
cargo runwithout--release, you're compiling in dev mode, which is skipping a lot of optimizations. it's worth trying in release mode and seeing how things go.@redactedontop commented on GitHub (Mar 23, 2025):
@DirectXMan12 shouldn't be a performance issue as it's due to query loss and not runtime speed.