bind9 & multiprocessing

[Jeffrey Cioli]

hi,

first, thanks for the response. i did try the "-n 2", and i saw 
no real difference in performance. i did notice that bind9 is
only using user threads; it's not using any kernel threads.

i have been doing some performance testing. for example, i 
have been testing ddns updates on 1, 5 up to 10 zones (1k rrs/zone).
basically, ddns update performance is pretty much the same
between bind8 and bind9. just speculating, but it almost appears that
the zone threads, in bind9, are being serialized. perhaps, kernel 
threads would help here. again, i'm just speculating...

i just downloaded b2. i saw performance, using the same tests,
get considerably worse - like 67% worse. note, i tried the same
tests but placing my zonefiles, named.conf and journal files in
/tmp (to eliminate disk io due to the journaling). performance, as
expected, greatly improves, suggesting ddns is io bound - i 
suspect due to journaling. b2 and b1 performance is basically the
same for the /tmp test. this causes me to believe that b2 has 
incurred greater overhead w/ respect to journaling. what
has changed here???

thanks
jeff

At 01:01 PM 3/23/2000 -0800, Bob Halley wrote:
>Jeffrey Cioli <jcioli at cisco.com> writes:
>
>> i have been experimenting w/ bind9 regarding ddns. 
>> i noticed a couple of things regarding performance.
>> first, bind9's performance is very similar to bind8.
>> i would think that the multithreading capability of bind9
>> would help. i ran my tests on both a uni-cpu sparc-u5 
>> (333 mhz) and a dual-cpu e250 (400 mhz each). i actually 
>> saw performance decreased on the dual-cpu e250. i would 
>> expect performance to increase. but, then ddns is io bound 
>> due to the journeling. 
>> 
>> is multithreading and multiprocessor support enabled for
>> bind9 b1 ???
>
>Yes.  Did you start the server with '-n 2'?  If you have multiple
>processors, you need to use the '-n' option to tell BIND 9 how many
>you have, so it can create an appropriate number of worker threads.
>
>Also, beta 1 doesn't yet call pthread_setconcurrency() or
>thr_setconcurrency() on Solaris, so that might be causing problems
>too.
>
>If all of your updates are to the same zone, you're going to see a
>limited benefit from the multiple CPUs, because all of the updates to
>any given zone are serialized.
>
>/Bob
> 


**************************************************************
"No snowflake in an avalanche ever feels responsible"