starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #367] More than a sec to resolve a query in localhost #465

New issue

Closed

opened 2026-03-15 22:39:51 +03:00 by kerem · 7 comments

kerem commented

2026-03-15 22:39:51 +03:00

Owner

Originally created by @RCasatta on GitHub (Mar 31, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/367

Hi,

I am trying out 7714b11474 on Mac OS X and Ubuntu 16.04, launching with:

$ ./target/release/named -c server/tests/named_test_configs/example.toml -z server/tests/named_test_configs/ -p 24141

and then

$ time dig @localhost -p 24141 www.example.com

and it takes more than a second (real 0m1.027s) to resolve

Originally created by @RCasatta on GitHub (Mar 31, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/367 Hi, I am trying out 7714b1147434845db1f28a0df16a9d90b163a8ff on Mac OS X and Ubuntu 16.04, launching with: `$ ./target/release/named -c server/tests/named_test_configs/example.toml -z server/tests/named_test_configs/ -p 24141` and then `$ time dig @localhost -p 24141 www.example.com` and it takes more than a second (real 0m1.027s) to resolve

kerem

2026-03-15 22:39:51 +03:00

closed this issue
added the
perf

wontfix
labels

kerem commented

2026-03-15 22:40:07 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 2, 2018):

Hi, thanks for the report. Based on your path I'm assuming you compiled with cargo build --release.

If you have some time, from the trust-dns/server directory, could you run the benchmarks? cargo bench

Off master, I'm currently getting:

test trust_dns_tcp_bench      ... bench:      87,361 ns/iter (+/- 5,550)
test trust_dns_udp_bench      ... bench:      71,554 ns/iter (+/- 6,375)

thanks.

@bluejekyll commented on GitHub (Apr 2, 2018): Hi, thanks for the report. Based on your path I'm assuming you compiled with `cargo build --release`. If you have some time, from the `trust-dns/server` directory, could you run the benchmarks? `cargo bench` Off master, I'm currently getting: ```console test trust_dns_tcp_bench ... bench: 87,361 ns/iter (+/- 5,550) test trust_dns_udp_bench ... bench: 71,554 ns/iter (+/- 6,375) ``` thanks.

kerem commented

2026-03-15 22:40:12 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 2, 2018):

Also, I notice in reproducing your results, dig is much faster if you explicitly put 127.0.0.1. The reason this would be the case is that first dig is making a system call to lookup localhost with the system resolver and then it's looking up www.example.com. with the trust-dns server.

I've never benchmarked with dig or host, and I don't think those are the best tools for benchmarking DNS performance. If that is something you're interested in doing, It would be interesting to get some independent tools for perf testing the server. The benchmarks in the library make use of the trust-dns client, which may bias and they are definitely narrow in what they are testing.

@bluejekyll commented on GitHub (Apr 2, 2018): Also, I notice in reproducing your results, dig is much faster if you explicitly put `127.0.0.1`. The reason this would be the case is that first dig is making a system call to lookup `localhost` with the system resolver and then it's looking up `www.example.com.` with the `trust-dns` server. I've never benchmarked with dig or host, and I don't think those are the best tools for benchmarking DNS performance. If that is something you're interested in doing, It would be interesting to get some independent tools for perf testing the server. The benchmarks in the library make use of the `trust-dns` client, which may bias and they are definitely narrow in what they are testing.

kerem commented

2026-03-15 22:40:17 +03:00

Author

Owner

@RCasatta commented on GitHub (Apr 2, 2018):

Also, I notice in reproducing your results, dig is much faster if you explicitly put 127.0.0.1. The reason this would be the case is that first dig is making a system call to lookup localhost with the system resolver and then it's looking up www.example.com. with the trust-dns server.

yes, localhost was the issue... Much faster with 127.0.0.1 like 31ms

I launched cargo +nightly bench anyway and on Mac OS X mid 2014 laptop I got

test trust_dns_tcp_bench      ... bench:      96,494 ns/iter (+/- 2,536)
test trust_dns_udp_bench      ... bench:      82,944 ns/iter (+/- 23,888)

I feel the two initial command I launched could be interesting in the Readme.md after the Running section for a quick test drive, would you like I make a PR?

@RCasatta commented on GitHub (Apr 2, 2018): > Also, I notice in reproducing your results, dig is much faster if you explicitly put 127.0.0.1. The reason this would be the case is that first dig is making a system call to lookup localhost with the system resolver and then it's looking up www.example.com. with the trust-dns server. yes, `localhost` was the issue... Much faster with `127.0.0.1` like 31ms I launched `cargo +nightly bench` anyway and on Mac OS X mid 2014 laptop I got ``` test trust_dns_tcp_bench ... bench: 96,494 ns/iter (+/- 2,536) test trust_dns_udp_bench ... bench: 82,944 ns/iter (+/- 23,888) ``` I feel the two initial command I launched could be interesting in the Readme.md after the Running section for a quick test drive, would you like I make a PR?

kerem commented

2026-03-15 22:40:22 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 2, 2018):

Sure! That would be great!

@bluejekyll commented on GitHub (Apr 2, 2018): Sure! That would be great!

kerem commented

2026-03-15 22:40:27 +03:00

Author

Owner

@RCasatta commented on GitHub (Apr 2, 2018):

When I tried to build the repo I found the target dir in the base dir, not in the server or client dir

Is my configuration or is the readme outdated?

@RCasatta commented on GitHub (Apr 2, 2018): When I tried to build the repo I found the target dir in the base dir, not in the server or client dir Is my configuration or is the readme outdated?

kerem commented

2026-03-15 22:40:32 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 2, 2018):

The Readme may be outdated. That was probably written before the projects were moved into a single workspace. After doing that, there is a shared target repo at the root. If you want to include that in your update, that would be great.

@bluejekyll commented on GitHub (Apr 2, 2018): The Readme may be outdated. That was probably written before the projects were moved into a single workspace. After doing that, there is a shared target repo at the root. If you want to include that in your update, that would be great.

kerem commented

2026-03-15 22:40:37 +03:00

Author

Owner

@RCasatta commented on GitHub (Apr 3, 2018):

https://github.com/bluejekyll/trust-dns/pull/369

@RCasatta commented on GitHub (Apr 3, 2018): https://github.com/bluejekyll/trust-dns/pull/369

kerem referenced this issue

2026-03-16 02:07:34 +03:00

[PR #465] [MERGED] make ClientHandle api return Send #1459