dnsperf and BIND memory consumption

[Vinny Abello]

> -----Original Message-----
> From: JINMEI Tatuya / 神明達哉 [mailto:Jinmei_Tatuya at isc.org]
> Sent: Thursday, August 07, 2008 2:45 PM
> To: Vinny Abello
> Cc: bind-users at isc.org
> Subject: Re: dnsperf and BIND memory consumption
>
> At Thu, 7 Aug 2008 01:20:46 -0400,
> Vinny Abello <vinny at tellurian.com> wrote:
>
> > One thing I am still confused about is why the performance of BIND
> > is slower (when measured with dnsperf) when the test data is for
> > authoritative data. I'm still seeing (with threads disabled now) non
> > authoritative answers clocking in around 14k queries per second and
> > authoritative answers at about 4k queries per second. Again, I tried
> > localhost and I just tried the PTR record for
> > 1.1.168.192.in-addr.arpa via queryperf. Dig confirms both are
> > authoritative answers from my 9.5.0-P2 server (and I know they are
> > based on the configuration), yet when doing queries for them I'm
> > getting about 1/3 the performance vs. random lookups for non
> > authoritative data. If anything I would think that data would be
> > faster.
>
> If the test for the recursive case really caused a lot of external
> queries and (mostly) succeeded, rather than SERVFAIL or something, and
> if I understand the test case, the result is indeed very
> counterintuitive.  I can't think of any possible theory that can
> explain it.

I further noticed that this only seems to happen for zones that I *think* BIND may have code built in to answer authoritatively... even though I have these zones manually defined in my named.conf as well. I tried another zone that is not part of the RFC1918 space of the in-addr.arpa zones or localhost and it was much faster like the recursive queries were. I tried this test on another server and noted the same behavior with in-addr.arpa zones in the RFC1918 space and with the localhost address on a totally different host OS being much slower than other local authoritative zones. So the results seem the same regardless of machine or platform. Maybe there is some code it is running through that is slowing response time on these queries? I noticed that the CPU load doesn't go anywhere near as high either on the named process when I get these results. I'm not sure what that may signify. Not necessarily a major problem, but an interesting set of inconsistent results regarding performance based on the data.

-Vinny