Performance Test Metrics for dns server performance.

[Brad Knowles]

At 7:17 PM -0600 5/4/01, Matt Simerson wrote:

>  Netperf2 doesn't do much other than make connections to the port. That's not
>  really what I'm after. I wan't to make queries AND evaluate the results.

	In that case, you need to make sure that your code is not the 
bottleneck.  You may need multiple testing machines to do this -- 
some of which generate background "noise" traffic to simply load the 
servers to a certain level, some of which are instrumented and are 
the ones you actually use to measure the performance of the server.

>  The first is to buy a HP server. The next performance boost is getting rid
>  of the stock version of BIND and making code changes. The last is optimizing
>  the compile using HP's ANSI C compiler which I don't want to experience
>  again. :-(

	But Rick does teach us some things that could be very useful in 
general, and I think it would be a mistake to categorize his papers 
as little more than HP marketing.

>  Already do the chroot thing with BIND. The rest doesn't matter until net
>  starts routing IPv6.

	I disagree.  I believe that DNSSEC and TSIG are important today, 
and IPv6 will be important very soon.

>  I've found one posting re:djbdns while searching the archives. You basically
>  stated that because it doesn't support "IPv6, TSIG, or any other advanced
>  features of the dns" that you don't consider it to be a viable replacemnt.
>  Heck, BIND 8 doesn't support the advanced features you mention. Quickly
>  reading through the lists tells me that I can't use BIND 9 either. Maybe
>  when all those features work...

	Not true.  IIRC, the original reference implementation was for 
BIND 4, then the work was ported forward to BIND 8.  At this point, 
BIND 9 implements more of DNSSEC, TSIG, IPv6, etc... than any other 
nameserver in existence, and I believe that it is the current 
reference standard implementation for these features.

	Moreover, I also believe that there are certain protocol 
violations that you see with djbdns and dnscache, and that these are 
as important (or perhaps even moreso) than the features that are 
lacking.

>  I drive a car that lacks features other cars have. It doesn't have GPS, no
>  TV for the back seat passengers, no DVD player in the dash, it doesn't
>  massage my backside as I'm driving down the road. That didn't stop me from
>  buying it. If it does the job well, it's worth considering.

	True enough.  However, when you look closely enough, I believe 
you'll find that djbdns and dnscache are lacking, just as I have.  Of 
course, this is a conclusion that you will have to reach on your own.

>  After reading that, it's very apparent that it's a much different test than
>  I ran. They were only doing lookups on a primed cache. I'm doing tests that
>  make the caching server go fetch the results. They isolated their tests from
>  the network with the priming. If only my real world servers had the luxury.
>  I don't doubt that both servers will tear through cached results much, much
>  faster. That's a VERY different test.

	The problem is that when you don't isolate the systems from the 
network, or at least put the systems to be tested on a completely 
isolated network where you control all the possible variables, the 
test results you come up with are pretty meaningless.

	At the very least, you need to do a "before and after" approach, 
where you isolate the systems from the network for one sequence of 
tests, and then you put the machines on the network and re-run the 
tests, to see what the differences are, etc....

>  I suspect that in my next round of tests (where I test against data in the
>  cache) I'll be seeing numbers much more similar to those. However, I am
>  using moderately priced PC hardware and 100BaseT as opposed to Gigabit
>  ethernet, 8GB of RAM, and a server in a different price ballpark.

	The systems you've described should have more than enough memory, 
and a NIC that should be more than fast enough.  They may be able to 
stand having a faster CPU (or more CPUs), but I believe that the 
largest single driving factor in your tests should be network latency 
and the latency of the remote servers that the data is being cached 
from.

	Gigabit Ethernet shouldn't really buy you anything in this 
context (I sincerely doubt you're ever going to generate enough 
traffic on these machines to saturate even 10Base-T, much less 
100Base-TX), and going into the multiple gigabytes of RAM shouldn't 
really buy you anything, either.

	One thing you may want to consider is the same sort of nameserver 
configuration that Kevin has discussed on this list -- namely, making 
your caching nameservers stealth secondaries for the zones that your 
other servers are authoritative for, and this should help 
significantly speed up their ability to resolve data in those zones.

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