DNS server caching performance test results.
Brad Knowles
brad.knowles at skynet.be
Fri May 18 00:17:02 UTC 2001
At 4:38 PM -0600 5/17/01, Matt Simerson wrote:
> I'm going to have to amend your statement to read: "Forwarding with BIND is
> evil" because DNS forwarding is certainly not an evil thing to do. In many
> networks it makes very good sense to have a cache hierarchy so that
> duplicate requests are handled within the LAN rather than having several
> hundred dns servers all querying the roots and the rest of the world.
If you were to do it right, I'd agree with you. However, since
99.9999999999999999999999% of the people out there can't seem to get
it right (from all the problems I've seen on this mailing list with
regards to forwarding), I fall back to my previous statement --
forwarding is evil.
Even if you do know how to set up forwarding properly, you
shouldn't use it because the guy who comes in behind you almost
certainly *WON'T* know how to do it properly, and then things will
break in the most bizarre ways, and no one will understand why.
Forwarding -- just say "NO".
> I have two numbers for you: the first is with logging stats and the latter
> is with no logging (on walldns). Your question made me go back and test it
> with logging completely disabled. It's interesting to note that I had stats
> logging enabled for the previously posted batch of tests.
>
> dnsfilter --> dnswall: 65535 requests in 27 seconds = 2621 qps.
> dnsfilter --> dnswall: 65535 requests in 10.4 seconds = 6301 qps.
Fascinating. So, with logging turned on for walldns, even though
it is intentionally reduced to the simplest possible program so that
it can be as fast as possible, it still isn't much faster than BIND 9
once the data has been cached. Interesting.
> dnscache 63 s 1040 qps ** stats logging (for reference)
> 26 s 2520 qps ** no logging
> 26 s 2520 qps ** cached
> 26 s 2520 qps ** cached
I'd like to see the results of the first test re-run with logging
turned off on the walldns server, to see what happens to the first
run numbers with the caching nameservers.
I'd also be really interested to see the performance of walldns
(with logging turned off) compared to BIND 9, both running on a
multi-CPU system. I would like to compare their ability to scale
with the added horsepower.
> None of the dns caches were able to even approach the new limit of 6300 qps
> that walldns is capable of. Since I can generate 6300 qps with one client,
> I'm making the assumption that I'll see similar results hitting it with
> three clients.
Now that you've got this data, that is a reasonable conclusion.
Perhaps it would be a bit excessive to follow my previous suggestion.
That said, you are not likely to find a better way to seriously
stress a nameserver than running multiple clients continuously
chewing through a list of questions to be asked, and doing so as
quickly as they possibly can.
> PS: Special thanks to Brad for all his very good questions.
You're welcome. I'm interested in benchmarking in general, and
in benchmarking nameservers in particular, and I'd love to be able to
help you find the most complete and accurate set of tests that you
can run.
--
Brad Knowles, <brad.knowles at skynet.be>
/* efdtt.c Author: Charles M. Hannum <root at ihack.net> */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers */
/* */
/* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */
/* where title-key = "153 2 8 105 225" or other similar 5-byte key */
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
More information about the bind-users
mailing list