Bind 9.1.3 stop resolving but is still running.

Brad Knowles brad.knowles at skynet.be
Thu Sep 6 23:32:01 UTC 2001


At 3:39 PM -0700 9/6/01, Nate Campi wrote:

>  I do have results from running against cached results, too, but I didn't
>  really need them. The task I'm stuck with is giving max performance for
>  an app that resolves IPs into hostnames for our reporting team (parsing
>  web logs, running reports on logs, etc). Caching performance is relevant
>  for in-addr.arpa delegations, but not much else in this case. The same
>  IPs are guaranteed (by the app author) to never get requested twice.

	Right, but two IP addresses that differ only in their last octet 
are likely to be served by the same nameserver, and the EDNS0 probe 
for that machine would be remembered from one query to the next.  An 
operation like this might only be run once a day, or maybe once a 
week, but there would still be a decent enough chance that a fair 
amount of that information would still be in the cache from the 
previous run, and therefore it would be entirely valid to compare a 
"clean" run against a "cached" run.

>  Agreed on the authoritative info benchmarks. BIND 9.1.3 does about 7000
>  queries/sec (non-threaded) on a Linux box of mine when queried from the
>  localhost, but around 2000 queries/sec from a host on the same network
>  segment (100 mbit full-duplex BTW, on both hosts). From across the
>  network (same BIND host and same querying host) BIND 8 handles 3100
>  queries/sec.

	Hmm.  It would be really interesting to have additional profiling 
information available from these runs, so that we can get a better 
idea of what is going on and why.  Did you build these copies of BIND 
yourself, and if so, did you use gcc or the vendor-provided compiler? 
If you used the vendor-provided compiler, there should be a lot of 
tools available to you to help figure out what is happening and why, 
and you should be able to turn on additional compiler optimizations 
to help improve the performance of the processes.

	Also, was BIND 9 built multi-threaded or single-threaded?

>  All these results are from queryperf running on Solaris 8 x86. I have a
>  whole mess of test results from BIND 8 and 9 running on Linux x86, and
>  Solaris 8 (both x86 and sparc), as well as dnscache. I'll make sure to
>  post it for review, and will invite instructions on how to better run my
>  tests.

	Keep in mind that building BIND 9 with gcc on Solaris 8 (or other 
64-bit Solaris) is not recommended or supported, because gcc has a 
very difficult time producing decent 64-bit code.  Indeed, I believe 
that ipfilter *still* refuses to build with gcc in 64-bit mode on 
Solaris, for precisely this reason.


	Myself, I'd be very interested to see performance testing results 
of Solaris 8 on x86 against Linux on x86 and FreeBSD.  Unless you're 
using the latest versions of the Linux kernel, I believe that there 
may be some issues with the threading library, and we already know 
about the issues with gcc on 64-bit Solaris.

	That would leave FreeBSD as probably the best platform on which 
to run BIND 9 on the x86 platform.

>  I trust you Brad, I see your name as a proof-reader for Cricket's book
>  ;) Thanks to you, Cricket and Paul, my duties as a DNS admin are much
>  easier.

	I appreciate the compliment, but regretfully I haven't really 
done any work on the book since 2nd edition.  I would really have 
liked to be on the review team for 4th edition, but it didn't happen.

	However, I'm now starting down the tortuous road towards perhaps 
writing my own book, so we'll see how that goes.

-- 
Brad Knowles, <brad.knowles at skynet.be>

H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA


More information about the bind-users mailing list