Performance Test Metrics for dns server performance.

[Matt Simerson]

> -----Original Message-----
> From: Brad Knowles [mailto:brad.knowles at skynet.be]
> Sent: Friday, May 04, 2001 4:31 PM
> To: Matt Simerson; 'bind-users at isc.org'
> Subject: Re: Performance Test Metrics for dns server performance.
> 
> In Message-Id <200104041440.IAA27131 at llama.swcp.com>, Bill Larson 
> <wllarso at swcp.com> mentions tools like the Perl script known as 
> "mresolv2", written by Mark Fuhr (of the Perl Net::DNS module fame) 
> and available at <http://www.fuhr.org/~mfuhr/perldns/>.

That'll be useful. :-)

> 	There is also the "netperf" tool developed by Rick Jones at HP (see 
> <ftp://ftp.cup.hp.com/dist/networking/briefs/named_performance.txt> 
> for more information).

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.
I've heard netperf3 does more fun stuff but I haven't got it to compile yet
on FreeBSD (my reference platform). I've got an OLD hp9000 at home. I
supposed I could resurrect it just to install netperf3 on but it's old and
would be very limited by it's 10baseT interface. <sigh>

> 	I strongly suggest that you read the various DNS & BIND related 
> articles that Rick Jones has made available at 
> <ftp://ftp.cup.hp.com/dist/networking/briefs/>.  After reading these 
> articles, you should have a much better idea of how to really stress 
> test your nameservers.

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. :-(

> 	That said, I would encourage you to also look at things like 
> IPv6, DNSSEC, running the servers in a chroot() environment, etc....

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

> If you do other searches in the archives for this list,  you will 
> find some comments that I have made regarding djbdns and dnscache. 

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...

> I won't repeat them here, but suffice it to say that I do not believe 
> that these programs are suitable for use in a production network, due 
> to their lack of support for certain features, aspects of the 
> protocol, etc....

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.

> 	That said, you obviously have to make up your own mind with 
> regards to these issues.
> 
> >    BIND 8.2.3-REL - 6-8MB - 90,112 requests
> >    1,000          1144      18,966         5,203          47,638
> >    10,000         1157      14,299         4,899          54,236
> >    100,000        1200      12,771         5,185          56,575
> 
> 	If you look at 
> <ftp://ftp.cup.hp.com/dist/networking/briefs/dns_server_results.txt >, 
> you will note that Rick Jones was able to get over twelve thousand 
> queries per second handled by BIND 8.2.2-P15, and never saw less than
> 3500 queries per second with a stock implementation of BIND on an HP
> L2000 with one 440Mhz processor.

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.

> This seems to me to be a much, much, much higher query rate per 
> second than you saw (~10.6425 to ~16.5 per second?!?), and I don't 
> understand why. 

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. 

Matt