[bind10-dev] performance improvements and regressions

[JINMEI Tatuya / 神明達哉]

At Tue, 12 Feb 2013 11:09:02 -0600 (CST),
"Jeremy C. Reed" <jreed at isc.org> wrote:
> 
> This is a comparison from the 1.0.0-beta-release from Dec. 20 to master 
> of today.
[...]
> Some very good improvements. But sqlite3 had all regressions.

The good ones are quite likely because of
http://bind10.isc.org/ticket/2310 I'd note, however, that this
optimization is not effective for all scenarios.  In particular, it
wouldn't help much for purely delegation centric zones.  In fact,
I didn't see much difference in my own measurement using a root server
setup.  But I'm still happy with this result as it suggest other
optimization suggested in #2283 will also be promising (for example,
#2286 will help delegation-centric signed zone).

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:

- delay conversion from text as long as possible; in many cases we
  only need to know whether a particular type of RR exists for a given
  name.  We could probably skip generating rdata (and RRset) in such
  cases.
- cache some apex RRs.  If we cache the apex NS and SOA and reuse it
  unless the zone is updated, we can avoid the conversion from the
  text for these records.
- (allow users to) use "minimal answer" option.  in general, reducing
  the number of RRs to produce will help improve performance, and that
  will also apply to this bottleneck.
- use non-text form of data for RDATA

---
JINMEI, Tatuya