[bind10-dev] auth statistics

[Yoshitaka Aharen]

Hello,

Thank you for your comments.

On Tue, 11 Sep 2012 07:51:19 -0500 (CDT)
"Jeremy C. Reed" <jreed at isc.org> wrote:

> > I've benchmarked the current implementation on branch trac2157 and the
> > base of the branch. I've tested with root zone (without DNSSEC RRs)
> > by querying "nic.${tld} SOA", and nonexistent TLD for 5 times. The
> > results show the overhead of the current implementation is about 9%.
> 
> That seems like a huge regression for just doing a few counters. Or does 
> this include transferring the stats to the stats server too? Where is 
> the performance lost?  I don't know if the overhead is acceptable, but I 
> wonder what BIND 9's overhead is when doing similar.
It's the overhead of incrementing counters without transferring the
stats to the stats as I used query_bench utility for benchmarking.
I've pushed some optimization to trac2157 (git d217636). The results of
query_bench shows improvement of overhead to 3%.

                 optimized      with stats   without stats
               (git d217636)  (git c0f1785)  (git 0880746)
              ---------------.--------------.--------------
existent
TLD qnames      326,070.56      305,510.74     335,556.132

with 50% of
nonexistent     322,912.91      302,843.95     332,706.824
qnames

> Can you tell me about your hardware and operating system? This is very 
> fast.
It's a VMware ESXi 4.1 virtual machine with 4 virtual CPUs and 2GB of
memory. It's on a blade which has Intel Xeon E5540 and 48GB of memory.
It runs Debian 6.0.5 (squeeze) amd64 with Linux 3.2. BIND 10 is compiled
with g++ 4.4.5.

> Also is this served using sqlite3 or in-memory?  (I assume it must be 
> in-memory, since I get about 50% slowdown for 100% nonexistent queries 
> using sqlite3. But it is also strange since for my in-memory, my 
> nonexistent queries are actually faster. If it is not in-memory, then I 
> am surprised by your less than 1% slowdown for 50% nonexistent.)
I tested with in-memory data source (sorry I forgot to show it). I don't
know why nonexistent queries are slower for my in-memory, but I didn't
mind it because the purpose is to check the overhead for statistics.

-- 
Yoshitaka Aharen <aharen at jprs.co.jp>
Japan Registry Services Co., Ltd.