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

BIND 10 Development do-not-reply at isc.org
Wed Oct 24 18:06:29 UTC 2012


#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      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:21 y-aharen]:

 > 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.

 In the context of serving a large number of zones I don't think this
 approach solves the main concern anyway.  In this case the major
 scalability challenge is that we cannot assume an upper limit of the
 number of zones and it won't be reasonable to assume holding the full
 statistics for all zones in memory.  I thought our approach for this
 issue is to only keep updating statistics for a subset of the zones
 for some specific period (like 30 sec, or until the amount of memory
 for the statistics reaches some limit) and periodically flushes it by
 transferring the data to the statistics daemon.  With this approach,
 it shouldn't be a big concern even if the size of the statistics data
 for a single zone is relatively large (e.g., having counters for all
 types up to 256, plus "others").

 BTW, the processing overhead (when incrementing) is not my main
 concern.  It's more about code maintainability.

 > 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.

 Hardcoding the conversion as a near term compromise is okay.  What I'm
 not convinced is to hardcode the particular RR types in places like
 auth.spec or `QRQTypeToQRCounterType`.

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


More information about the bind10-tickets mailing list