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:  jinmei                     
          Type:  task        |       Status:  reviewing                  
      Priority:  major       |    Milestone:  06. 4th Incremental Release
     Component:  statistics  |   Resolution:                             
      Keywords:              |    Sensitive:  0                          
Estimatedhours:  0.0         |        Hours:  0.5                        
      Billable:  0           |   Totalhours:                             
      Internal:  0           |  
-----------------------------+----------------------------------------------
Changes (by naokikambe):

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


Comment:

 Please don't worry about not doing sooner. :)

 Replying to [comment:18 jinmei]:
 > I'm not sure if I understand this part.  Do you mean an auth server can
 run for a long time (e.g. several years) and a monotonically increasing
 counter may overflow?  If so, I don't know how the number of auth servers
 (btw what this means?  the number of auth server processes/threads
 assuming we adopt a multi-process/thread server model?) is related to the
 point.  Also, should we really worry about overflow in a realistic
 scenario?  Suppose we handle 100,000 qps, and have a counter of number of
 queries.  If it's a 64bit unsigned integer, it won't overflow until
 368,452,886,146 years later.  Even if it's 32bit, it won't overflow until
 85 years later.

 Replying to [comment:20 jinmei]:
 > Replying to [comment:18 jinmei]:
 >
 > > Suppose we handle 100,000 qps, and have a counter of number of
 queries.  If it's a 64bit unsigned integer, it won't overflow until
 368,452,886,146 years later.  Even if it's 32bit, it won't overflow until
 85 years later.
 > >
 > Sorry, I've noticed the calculation was incorrect.  These should be
 5,849,424 years and 0.0014 years, respectively:
 >
 > {{{
 > >>> 2**64 / (3600 * 24 * 365 * 100000)
 > 5849424.17355072
 > >>> 2**32 / (3600 * 24 * 365 * 100000)
 > 0.0013619251953323186
 > }}}
 > (ignoring leap years)
 >
 > 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.

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