[bind10-dev] auth statistics

[Yoshitaka Aharen]

Hello,

Sorry for late response.

I have implemented query/response counters in the way to have an
abstraction for query/response attributes. With current 'collect
attributes' phase, all of query/response attributes are collected.
'update the corresponding statistics counters' phase is in the class
isc::auth::statistics::Counters. We can introduce another kind of items
for query attributes with modifying statistics.cc and statistics_items.h.

As pointed in the comment on ticket #2154, regarding scalability to
add RRtypes, it is a grind to add enum definitions not only to define a
class which inherits isc::dns::rdata::Rdata. However, it is also
required to add an item name in src/bin/auth/statistics_items.h.
If it can be auto-generated from Rdata class, also enum definition can
be.

Some of if-else's have been removed with table lookup in git 6760e04.
The others are necessary for two stage of operation; collect attributes
and then update the corresponding counters.

I've benchmarked the current implementation on branch trac2157 and the
base of the branch. I've tested with root zone (without DNSSEC RRs)
by querying "nic.${tld} SOA", and nonexistent TLD for 5 times. The
results show the overhead of the current implementation is about 9%.

(Average qps)
                with stats   without stats
              (git c0f1785)  (git 0880746)
              --------------.--------------
existent
TLD qnames      305,510.74     335,556.132

with 50% of
nonexistent     302,843.95     332,706.824
qnames

> As we discussed in the biweekly call yesterday, I think we need some
> more design-level discussions on how to manage statistics counters for
> b10-auth before proceeding with tickets #2154, #2155, and #2157.  I'd
> like to have a project-wide discussion about
> 
> - how to represent these counters (it may be different for different
>   types of statistics, e.g., generic counters like total # of incoming
>   requests vs per-RR type queries).
> - how to update these counters with minimizing performance impact on
>   query processing, maybe with prototyping and benchmarking
> - how to exchange these counters with external modules (which will
>   mainly be b10-stats, but can be in general).  This is probably
>   mostly trivial, but I guess we need to consider how to *cleanly*
>   convert things like per RR counters into JSON representation.
> 
> Then, on top of these, implement the concept in the above tickets.
> The end result may be the same, but I want to do it after fully
> discussing the design and performance impacts.

We would like to introduce this feature by the release in September.
If the overhead is acceptable, we'd like to put it in the release after
reviewing and then refine the design in another ticket.

Thanks,

-- 
Yoshitaka Aharen <aharen at jprs.co.jp>
Japan Registry Services Co., Ltd.