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