BIND 10 #170: document how stats are collected (via spec files)

[BIND 10 Development]

#170: document how stats are collected (via spec files)
-----------------------------+----------------------------------------------
      Reporter:  larissas    |        Owner:  naokikambe                 
          Type:  task        |       Status:  reviewing                  
      Priority:  major       |    Milestone:  06. 4th Incremental Release
     Component:  statistics  |   Resolution:                             
      Keywords:              |    Sensitive:  0                          
Estimatedhours:  0.0         |        Hours:  0.12                       
      Billable:  0           |   Totalhours:  0.5                        
      Internal:  0           |  
-----------------------------+----------------------------------------------
Changes (by jinmei):

  * hours:  0.0 => 0.12
  * owner:  jinmei => naokikambe
  * totalhours:  0.5 => 0.62


Comment:

 Replying to [comment:21 naokikambe]:
 > Please don't worry about not doing sooner. :)
 >
 Thanks, but please don't hesitate to kick me.  I'm lazy:-)

 > > But a 64bit counter still seems more than enough.
 >
 > Yes, I was afraid about overflow of integer at first, but I now don't
 need to be afraid it by this proof.
 > It is realized that it is enough in both 32bit and 64bit integer in
 python. We don't care whether we should use 32bit or 64bit in python. In
 this stats module, the query counts are set in python variables.
 >
 > The stats module wants the auth module to throw numbers of queries
 periodically by ''increase'' methods or ''set'' method, which are defined
 in spec file of stats module. The auth module can choose which methods to
 throw query counts. The stats module can handle it whichever methods the
 auth module choose.
 >
 I still don't get it.  If we don't worry about overflow, and if the main
 purpose of the ''increase'' method was to work around overflow scenarios,
 why do we need it?  If it could be implemented very easily that might not
 be a big deal (although we should still be careful not to add knobs that
 are not really necessary), but as I pointed out before, this would require
 the sender (typically the auth/recursive server) maintain complicated
 states in addition to the simply total counter.  So, to me, supporting
 ''increase'' seems to make the implementation complicated for non existent
 purposes.

 If the above understanding of mine is correct, I'd suggest
  - the sender (auth server, etc) only maintains a monotonically increasing
 "total" counter
  - we only provide the ''set'' method
 at least for the initial implementation.

 If, in future, we see a strong need for the ''increase'' method, we may
 consider how to do that at that point.  It's easy to start with a minimal
 set of necessary features and to extend it as we see the need for it; the
 reverse is not easy (actually often impossible due to compatibility
 reasons).

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