[bind10-dev] recent performance improvements

[JINMEI Tatuya / 神明達哉]

At Mon, 19 Mar 2012 16:12:27 -0500 (CDT),
"Jeremy C. Reed" <jreed at isc.org> wrote:

> > These don't generally match my expectation or my personal experimental
> > results - it should be much, much faster, especially for some specific
> > cases like "root-memory-.success".  Is this a result for the "false"
> > target (as we discussed via jabber Friday) or the real master?
> 
> The root-memory-.success did have 69% improvement over older BIND 10, 
> just still much slower than BIND 9 for my tests.

I bet there's something wrong in the test setup.  I did my test again
on the bind10-testing1 box.  All cases were for single thread/worker
thread.  The root zone case, using your root.zone-canonical zone file,
sending "www.google.com/A" repeatedly by queryperf for 30 seconds as
follows:
% ./queryperf -p 5300 -l 30 < google-input.txt

And the results are:
bind10 master (as of da4d1f0): 18456.889077 qps
bind10-devel-20120301: 5974.164548 qps
BIND 9.9.0 with acache: 15623.738072 qps
BIND 9.9.0 without acache: 10005.986613 qps

(And I believe with #1784 merged "BIND10 master"'s result will go over
20Kqps)

Does your tested "master" really contain the following tasks?
#1568, #1599, #1600, #1603, #1608, #1747

At Mon, 19 Mar 2012 16:12:27 -0500 (CDT),
"Jeremy C. Reed" <jreed at isc.org> wrote:

> There were some regressions in performance from a couple days earlier 
> too:
[snip]
> Maybe the #1568 and/or #1608 caused some of these regressions? I may do 
> performance tests for each merge point and parent of the merge for each 
> of the performance tickets.

#1608 shouldn't have any effect on the scenarios using the old data
source API (builtin and sqlite3).  It's also less likely that #1568
causes any regression.

Regression for sqlite3 cases may be due to #1603 (experiments suggest
it could be a bit slower than the previous renderer implementation if
the number of names to be compressed is small).

But I'd first like to be very sure that the tested code is a real
master containing recent performance related changes.  Frankly, I
cannot think of any other reason for the not-so-exciting or even worse
results than you checked out the wrong branch.  Maybe can you
copy-past for the first 20-30 lines of git log --pretty=format:"%h
%s"?

---
JINMEI, Tatuya