[bind10-dev] More ideas about high-performance data-source backend (warning: long text)

[JINMEI Tatuya / 神明達哉]

At Fri, 8 Oct 2010 12:57:32 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > I don't think my experimental code is so useful for your purpose
> > because
> > - it has other features (such as offset-based pointers to support
> >   mmap-based loading), which would be just noisy for you
> > - other than that, the tree structure itself is a simpler port of BIND
> >   9's rbt.  so you might rather want to see the original
> >   implementation.
> 
> I didn't mean the tree itself, but the other parts ‒ the pointers between RR
> sets, name compression hints, bindings to the data source API and so on.

Ah, okay.  I suspect it's not so useful for your purpose because the
implementation is so ad hoc.  But feel free to look into it if you are
interested.

> > - but in terms of overall server performance, it also depends on how
> >   many times we need to perform lookups for a single query.  if we can
> >   minimize that (NSD and BIND 9's "acache" take that approach) the
> >   lookup bottleneck would become relatively minor.
> 
> I think the tree structure is completely ortogonal to the optimisations you
> mentioned, like the hints for compression and pointers between RRsets you
> mentioned in the presentation.

May or may not be so.  I cannot just be so sure about that until I see
the specific data structure.

> > As for your specific proposal, I think we need a figure:-)
> 
> By figure, you mean a picture of it or some numbers? The first probably can be
> done easily, the second would mean a lot of guessing and computing, what I
> proposed is based partly on some experience, gut feeling and guesswork.

I meant a picture (drawing).

> > One quick thought that occurred to me is whether we can (efficiently)
> > update this DB without keeping the good property of locality.
> 
> Like you ask how hard it would be to make an update?

My question is, after updates whether we can still keep the structure
where we can minimize TLB misses.

> Do you think it makes sense to put it somewhere on wiki, or it is enough I
> remember it?

Putting it on the wiki is always good, if you have time:-) but since
this is not an urgent task it's up to you.

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