[bind10-dev] experiments with high performance on-memory data source

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Tue Jun 8 07:05:58 UTC 2010


As some of you already knew, I've been playing with an idea of o high
performance on-memory data source for BIND 10.  Although it's way too
incomplete, intermediate results look quite promising, so I'm going
to share them here.

The key features of this data source are:
- employing optimized zone data structures and query logic for much
  higher response performance as an authoritative name server
- directly mmap'able binary form so that the zone data can be loaded
  literally "instantly" regardless of the size of zone

As for response performance, benchmark tests indicate that it could
run 2-3 times as fast as BIND 9.

Here are some numbers from the benchmark tests.  I used a FreeBSD 7.2R
machine (disabling SMP) with AMD64 2GHz, 2GB Ram, and performed
queryperf running on a different machine connected to the test machine
via a GbE link.

- Root server configuration
  I used a recent snapshot of the root zone data, removing DNSSEC
  related records (because the experimental implementation didn't
  handle DNSSEC yet), and a (old) real query sample to a F-root
  instance.  queryperf results are:
  + BIND 10 (experimental): 53297qps
  + BIND 10 (current): 122qps
  + BIND 9 without acache: 13944qps
  + BIND 9 with acache: 20713qps
- .net server configuration (as an example of a huge zone)
  Using a snapshot zone file of the .net zone taken a few years ago,
  containing about 8.5M RRs.  I didn't have a realistic query sample
  for this zone, so I extracted queries used in the root test those
  whose qnames are under .net.  queryperf results are:
  + BIND 10 (experimental): 52498qps
  + BIND 10 (current): didn't respond
  + BIND 9 without acache: 22178qps
  + BIND 9 with acache: 27520qps

I guess I should note a few points for the "BIND 10 current" results.
These are results with the currently available version of BIND 10
using sqlite3-based data source.  Although it looks so poor, I'm not
so disappointed with the result.  This version is a proof of concept
version to show how we can apply our architecture to general purpose
database engines, and we know the underlying implementation is
currently inefficient (e.g. involving lots of data copies or expensive
string manipulation).  I believe many of the obvious bottlenecks can
be eliminated pretty easily.

On the other hand, the result for the "current" version with the .net
case may be a real issue.  I suspect the server mostly stalled in a
call to the sqlite3 library because the underlying DB is huge (about
1.1GB of sqlite3 file).  I don't know how to deal with this type of
problem with sqlite3, but it's pretty clear we need something

Finally, I must note that the comparison is not actually fair.  This
experimental implementation cuts many important corner cases,
including CNAME/DNAME handling, empty node matching, DNSSEC
considerations, multiple zones with (some notion of) zone table,
advanced options such as rrset ordering, etc.  But I'm quite sure a
full implementation will still be much, much faster than BIND

JINMEI, Tatuya

More information about the bind10-dev mailing list