DNS server caching performance test results.

[Brad Knowles]

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,$_)}'