BIND 10 #2157: Create an interface to pass statistics counters in Auth module

[BIND 10 Development]

#2157: Create an interface to pass statistics counters in Auth module
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  y-aharen                           |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20121106
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  b10-auth                           |  Estimated Difficulty:  8
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by y-aharen):

 * owner:  y-aharen => jinmei


Comment:

 Hello,

 Sorry for late response.

 Replying to [comment:19 jinmei]:
 > Replying to [comment:18 y-aharen]:
 >
 > > I had misread your comment and split parametrized counters.
 >
 > Sorry, maybe I wasn't clear enough.  That's not what I meant.
 >
 > My point was whether we decided to hardcode all specific RR types like
 > this:
 >
 > {{{
 >             "qtype": {
 >                 "a": 0,
 >                 "ns": 0,
 >                 "md": 0,
 >                 "mf": 0,
 > ...
 >                 "dlv": 0,
 >                 "other": 0
 >             },
 > }}}
 >
 > (and same goes for opcode, rcode, etc).  I don't remember we did, and
 > I personally would like to avoid this type of hardcoding in general
 > (if I sounded differently when we met face-to-face last month, I was
 > probably unclear and I apologize for that - but I never liked that
 > hardcoding).
 >
 > What I personally would like to see is, at the concept level, that we
 > only have something named "qtype" counters.  This name is the only
 > hardcoded information.  In an actual implementation of this counter,
 > there would be some form of array or vector internally, and its
 > `increment()` method takes `RRType`, identifying the appropriate
 > array/vector index, and increment the value there.
 >
 > {{{#!cpp
 > class RRTypeCounter {
 > public:
 >     void increment(const RRType& type) {
 >         const size_t code = type.getCode();
 >         if (code < SOME_THRESHOLD) {
 >             ++counters_[code];
 >         } else {
 >             ++counters_[OTHER_INDEX];
 >         }
 >     }
 > private:
 >     uint64_t counters_[SOME_REASONABLE_VALUE];
 > };
 > }}}

 I understood your suggestion. However, I'd prefer current approach.

 For BIND 9 compatibility we need to collect query RRtypes listed above. It
 is more memory-efficient to store only predefined types than to limit
 types with threshold, as the types are sparse. In case to serve large
 number of zones, memory efficiency is important. The overhead is
 reasonable as shown before.
 Currently the types are hardcoded in the source file and it's not the best
 way. Improving it will be in another ticket with considering to utilize
 libdns++ to convert RRtype into statistics item names.

 Thanks,

-- 
Ticket URL: <http://bind10.isc.org/ticket/2157#comment:21>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development