DNS server caching performance test results.
Matt Simerson
mpsimerson at hostpro.com
Thu May 17 22:38:59 UTC 2001
> -----Original Message-----
> From: Brad Knowles [mailto:brad.knowles at skynet.be]
> Sent: Thursday, May 17, 2001 1:04 PM
> To: Matt Simerson; 'bind-users at isc.org'
> Subject: RE: DNS server caching performance test results.
>
> At 11:59 AM -0600 5/17/01, Matt Simerson wrote:
>
> Forwarding is evil, and should be avoided if at all possible. It
> just doesn't work the way people expect it to, and it causes far too
> many weirdnesses if/when it goes wrong.
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.
> IMO, it's better to just turn off forwarding altogether.
You think it's evil, I don't. We'll have to disagree.
> And what happens when you point your clients directly at the
> "walldns" server itself? What kind of performance can you get out of
> it when you don't have to go through the caching nameservers?
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.
On that note, I've just re-ran several of the tests with a single client.
So, here's some updated numbers. The differences between this test and the
last is walldns and dnscache are running with NO logging (BIND has logging
disabled by default) and output is sent to /dev/null instead of a file.
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
BIND 8 18 s 3640 qps
39 s 1680 qps ** cached
39 s 1680 qps ** cached
BIND 9 79 s 830 qps
29 s 2260 qps ** cached
29 s 2260 qps ** cached
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.
Matt
PS: Special thanks to Brad for all his very good questions.
More information about the bind-users
mailing list