[bind10-dev] auth statistics

[JINMEI Tatuya / 神明達哉]

At Fri, 07 Sep 2012 19:52:25 +0900,
Yoshitaka Aharen <aharen at jprs.co.jp> wrote:

> I've summarized my opinion for the points of discussion. Your comments
> and suggestions are welcome by Sept. 19th.

Overall it seems to make sense to me.

Some specific comments  below:

> * representation of counters
> Statistics counters in auth are split into these 4 parts:
>   - Generic counters
>       protocols carrying the query, header flags, TSIG, ...
>   - Opcode counters
>   - RRType counters
>   - Rcode counters
> 
> For RRType and Rcode counters, I think it's not a good idea to implement
> them as a sort of array which is 64K size. Besides most of them are
> never used, all of them must be initialized with 0 at initialization. It
> causes page allocation. At the point of implementing per-zone statistics
> counter, it will be a problem. I'd like to limit the types (as in
> trac2157). As DSC displays only very limited set of the types, I think
> most of operators are especially interested in well-known types.

Personally I'm okay with using the compressed counter table for
RRType and Rcode (although the DSC argument doesn't seem to be very
strong - it doesn't make much sense to restrict our own functionality
just because a particular independent tool doesn't have that
functionality).

> * updating counters
> The implementation in trac2157 is divided into two parts; collecting
> attributes inside query processing and updating counters at the end of
> query processing. The approach has 9% of overhead and may be less
> efficient than updating counters directly inside query processing.
> However, thinking about per-zone counter, it is hard to implement in the
> approach. For per-zone counter, it is required to lookup a zone which
> the qname belongs to. It is impossible to update some per-zone query
> attribute counters as the lookup is done in the middle of query
> processing.
> I'd like to keep the approach and do some optimization. I think making
> some functions inline reduces overhead. I'll update the code and will
> take a benchmark.

I'm not so sure if it's fundamentally difficult/impossible to
implement per-zone statistics without a helper "attributes".  In fact,
BIND 9 implements this concept without such a helper.

This will ultimately depend on how the resulting code looks like, but
at the moment I'm okay with the proposed approach.  I see some
advantages in the "attributes" approach, so as long as it's
sufficiently fast and the code is clean and understandable, it'll be a
matter of preference.

As for the performance, the 3% overhead (measured by query_bench) is
probably acceptable as the real overhead including network I/O will be
much smaller than that.

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