DNS performance testing - FreeBSD & Solaris - BIND & djbdns
Brad Knowles
brad.knowles at skynet.be
Fri Jun 22 17:55:35 UTC 2001
At 11:08 AM -0600 6/22/01, Matt Simerson wrote:
> We started testing with 8.2.3 and changed over to 8.2.4 when it became
> released. All the published numbers are from 8.2.4 and 9.1.2-REL.
I'd like to see this level of detail become a standard part of
future versions/updates to this report. ;-)
> I wouldn't mind seeing them too by my test servers are gone. We weren't even
> considering BIND 9.2 as a platform to roll out into production so there
> wasn't much point in testing it. The numbers could be interesting through.
The numbers would be very interesting for me to see, in
particular since there has been working done in BIND 9 to avoid some
of the malloc() bottlenecking problems that were previously
identified by Rick Jones. I wouldn't be too surprised to find that
BIND 9.2 was actually released by the time you were ready to push
something into actual production (although you may not yet feel
comfortable with using it in production).
> That's because they weren't there. I can't say why but when I installed a
> default BIND 9.1.2-REL on the Solaris machine it broke BIND 8 to the point
> where it wouldn't answer queries. Our sysadmins customize Solaris enough
> that things weren't where I expected and I don't know Solaris well enough. I
> just turned it back over to them and had them install BIND 8.2.4 and I
> tested against that.
I can't imagine that installing BIND 9 should actually cause such
serious problems for Solaris. IIRC, Solaris is one of the primary
development/testing platforms for BIND 9, so there must have been
some other problems or mis-configuration that kept it from working
correctly.
> BIND reads zones files from disk into it's cache and serves them from there.
> Authoritative requests on BIND are the same as cached requests.
I'd still be interested in seeing an explicit BIND authoritative
test. Even if the numbers do turn out to be exactly the same, I'd be
interested to know things like how long it takes to load zones of
certain sizes, etc....
This would also help show up any differences between BIND 8 and
BIND 9 as authoritative servers.
> I do that to populate the cache.
I understand, but I believe that there are better ways to
populate the cache, and which avoid any potential issues with
forwarding.
> With dnscache that's implicit when we configured it to forward the requests
> for 216.in-addr.arpa so it wasn't an issue but we ended up having to do that
> with BIND.
No, you're misunderstanding. I believe that forwarding should be
completely avoided. Period.
I keep saying "set up the caching nameserver to also be
authoritative and delegate the child zone to be queried" and you keep
saying "forwarding". The two statements are mutually exclusive.
> While watching the queries with snoop we were seeing BIND query
> the root name servers upon every query of an IP within the in-addr.arpa
> space. That was particularly bad behavior.
Yes, indeed. That would be particularly bad behaviour. Were you
seeing this with both BIND 8.2.4-REL and 9.1.2-REL, or just one of
them and not the other?
--
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,$_)}'
More information about the bind-users
mailing list