[bind10-dev] performance improvements and regressions

[JINMEI Tatuya / 神明達哉]

At Wed, 13 Feb 2013 09:28:21 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > As for the regressions, a quick run of git bisect suggested that it's
> > because of the overhead introduced with #2390 and #2656 (especially
> > the former).  We now use the generic lexer to convert plain text
> > stored in the DB to Rdata.  While it works more accurately, it could
> > be more expensive.  I don't think we have to worry about this level of
> > performance regression for sqlite3 right now, but for longer term we
> > can do several things to make it more efficient:
> 
> I wonder, what is the bottleneck with sqlite3, if it's CPU processing or disk
> access. But I guess it would be cached for reading in the OS page cache.

I've not looked into such micro level profiling, but, in general, my
experiments (not surprisingly) showed that interaction with DB backend
is the most significant bottleneck in the overall query processing
performance.  That's the case even for such a lightweight backend as
SQLite3.  DNS query processing is basically pretty cheap, so I guess
any interaction with the low level system such as disk IO, even if the
data are cached in memory, can be relatively substantial.

As such...

> Anyway, for some server-driven databases (like mysql), there'll be other
> bottleneck ‒ the communication, when the data travel from bind10 to the SQL
> server and back. We may overcome this by running the bind10 in enough instances,
> but I wonder if it would be possible to batch the queries somehow (get all the
> RRs we need at once instead of taking multiple queries, like asking for apex RRs
> and the queried name at once).

...any attempt of reducing the number of necessary DB queries per DNS
query should help, possibly quite substantially.  And I previously
showed one possible way to do it for identifying the correct zone for
the query name:
https://lists.isc.org/pipermail/bind10-dev/2012-October/003866.html
(look for "Reduce the number of DB queries").  There may be other
similar optimization possible for queries within the zone.

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