[bind10-dev] new in-memory zone data design

[JINMEI Tatuya / 神明達哉]

At Wed, 20 Jun 2012 11:29:55 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> However, my biggest concern is, this looks complicated like hell. I
> don't know if we have time for all this logic and if we won't get
> lost in it.

Focusing only on this point again, so we don't lose the highest level
point that can affect plans most:

I'd first like to clarify that discussions between RB-tree vs AVL or
other type of trees are not critical in this context.

The initially proposed version is a result of trying to achieve best
possible performance both in terms of memory footprint and query
processing performance by
- compressing as much data as possible (e.g., avoid storing duplicate
  domain labels)
- storing RDATA in render-ready format and using that data directly
  for building responses
- enabling shortcut pointers for RDATA names for faster additional
  section processing (and possibly faster name compression)

The resulting performance is of course subject to measurement, but my
gut feeling is that it could be several times faster than BIND 9, and
closer to other implementations that solely focus on response
performance.

As for necessary development time, my guess was 2-3 sprints, but like
performance I could be wrong.

If we don't think that level of higher performance or we don't think
we can afford the expected development time, I can think of a couple
of alternatives:

1. just give up name shortcuts.  This is mostly equal to the current
   BIND 9's design (without acache).  And the resulting performance in
   query handling and memory consumption would be more or less
   equivalent to BIND 9.  It will be slower than BIND 9 that enables
   acache, especially for environments like top level domains
   (delegation centric, often requires a few to many additional
   records).  I guess the required development time would be half of
   that of the full version.
2. give up name shortcuts, and store full name data in tree nodes
   instead of portion of it.  We probably still do search for the
   effective label sequence only.  This will require more memory (it's
   closer to NSD, which maintains all names in a single RB tree where
   each node represents a complete domain name), but query processing
   can be faster because of the easier access to names.  It's
   difficult to guess its performance compared to BIND 9 with acache,
   but that's probably somewhat equivalent.  Development will be even
   much easier because it's more closer to our current implementation,
   but the difference in total development time between this 1 and
   first option would be marginal.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.