Performance of Bind 9.2.3 vs BIND 4.8.3
nishant
nishant80 at gmail.com
Fri Oct 15 06:26:03 UTC 2004
Hello Jim,
Phew! That was quite exhaustive.
I thank you for your response, it has helped a lot in understanding
the idea behind BIND 9.
But still i need to show that 'performance' wise BIND 9 is better than
BIND 4. And by "show" i mean to show by some kind of metrics.
Can u please help me in deciding what kind of tests should i really be
doing to show that BIND 9 'performs' better (or much better, as you
say) than BIND 4?
> All your tests show is that BIND4 is quicker at answering from its
> cache than a BIND9 server. This should surprise no-one. But even that
> doesn't make a compelling case for sticking with long-dead code. You've
> only measured one aspect of a name server's performance. What about
> the times to load a zone file or to resolve names that aren't cached?
One more point to make things clear.
I am querying the nameservers directly (by specifying the IP address
of the nameserver in the /etc/resolv.conf file).
And I am using my own test data (Zone file) to resolve the host names.
eg. gethostbyname("machine1.myzone.com");
As per my understanding, there is no question of nameserver returning
cached data in this case, right?
Thanks,
Nishant
Jim Reid <jim at rfc1035.com> wrote in message news:<ckmie5$19sl$1 at sf1.isc.org>...
> >>>>> "nishant" == nishant <nishant80 at gmail.com> writes:
>
> nishant> Hello All, I want to upgrade from BIND 4.8.3 to BIND 9.2.3.
>
> Don't even think about it, just do it! BIND4 is *dead*.
>
> nishant> I am using the above piece of code to send queries to: 1)
> nishant> A BIND 9.2.3 nameserver and, 2) A BIND 4.8.3 nameserver
>
> You'd be better off using queryperf in the BIND9 distribution for this
> sort of benchmarking.
>
> nishant> I took about 50 readings for both nameservers. The
> nishant> readings of this test reflect that the response time (the
> nishant> value of query_time) in case of the 9.2.3 server is
> nishant> almost 50% more than the 4.8.3 server. i.e, a 50%
> nishant> performance degradation.
>
> nishant> This is holding me from upgrading the DNS. I know that it
> nishant> may be argued that BIND 9 provides security features --
> nishant> etc. But, what is the point when the most basic query
> nishant> processing is not very efficient?
>
> BIND4 is dead. That's enough justification by itself. Some of the root
> servers -- who get orders of magnitude more queries than your server --
> run BIND9. None run BIND4. There are very good reasons for that. Query
> throughput isn't everything, even for the guys running the busiest
> name servers on the net.
>
> All your tests show is that BIND4 is quicker at answering from its
> cache than a BIND9 server. This should surprise no-one. But even that
> doesn't make a compelling case for sticking with long-dead code. You've
> only measured one aspect of a name server's performance. What about
> the times to load a zone file or to resolve names that aren't cached?
>
> It's also unlikely that the raw throughput of your name server will
> actually be noticeable. Does it *really* matter if an application gets
> its DNS query answered in 4 milliseconds instead of 2? Perhaps it
> might for an application that made hundreds of DNS queries per second.
> But there are very few applications that have anything like those sort
> of characteristics.
>
> BTW, some authoritative-only (non-BIND) DNS implementations are at
> least an order of magnitude faster than even BIND4 is at answering
> queries. Take a look at the open-source NSD or Nominum's ANS if raw
> throughput really matters.
>
> nishant> As far as my understanding goes, BIND 9 servers are
> nishant> supposed to perform better than BIND 4 servers, isn't it?
>
> It depends on your definition of "better". If the criterion is raw
> throughout from cache, BIND4 will be quicker because it isn't
> encumbered with the extensive sanity checking that's in BIND9. OTOH if
> your criteria include support for the latest DNS protocol features,
> protocol conformance, ease of administration, code quality, security,
> future-proofing for new protocol features, support for threading and
> huge address spaces, proper handling of query restarts, etc, etc,
> BIND9 wins. And BIND9 is very far from dead. From that perspective,
> it couldn't be any clearer which performs better.
More information about the bind-users
mailing list