[bind10-dev] recent performance improvements

[JINMEI Tatuya / 神明達哉]

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

> bind9 without configuring with enable-threads is much slower (than with 
> threads and no -n):

> root-memory-.nxdomain 38795.851265 qps 37% slower
> root-memory-.soa 27575.709109 qps 53% slower
> smallzone-memory-.nxdomain 45813.296888 qps 26% slower
> smallzone-memory-.soa 41170.656323 qps 34% slower
> smallzone-memory-.success 41824.596342 qps 32% slower
[...]

> So even when using the non-optimum BIND 9, BIND 10 is still slower for 
> me:

To be clear: if you mean "disabling threads" by non-optimum, comparing
to "without specifying -n", then I would say it's different from
"non-optimum".  It's just unfair (or misleading) comparison:

- disabling threads: uses exactly one core
- enabling threads, not specifying -n: uses as many cores as available

In the context of comparing BIND 9 and BIND 10, it just doesn't make
sense to compare "enabling threads without -n" BIND 9 with a
single-process b10-auth if the machine has multiple cores.

> root-memory-.nxdomain 29075.203829 qps 25% slower
> root-memory-.soa 19025.823065 qps 31% slower
> smallzone-memory-.nxdomain 30719.644537 qps 33% slower
> smallzone-memory-.soa 28879.885552 qps 30% slower
> smallzone-memory-.success 30725.390836 qps 27% slower

Okay.  In these cases the overhead that #1784 would eliminate should
matter substantially (because query processing and response building
are much cheaper), so let's revisit these cases after #1784 is merged.
From a quick check it should at least be more than "no slower than
bind 9":

Root zone case, single process b10-auth, sending a query for a non
existent name (www.google.noexist/A):

BIND 10 master as of da4d1f0: 29474.380127 qps (matches your result above)
BIND 10 #1784:                40413.568546 qps

---
JINMEI, Tatuya