[bind10-dev] List of the statistics tasks which JPRS plans to work for in year 5

Naoki Kambe kambe at jprs.co.jp
Thu Mar 28 06:06:14 UTC 2013


Hello Jinmei-san,

Thank you for comments.

> >  - Are these enough for statistics work of year 5?
> 
> I'm afraid it's difficult to answer, but, in general, we can improve
> the amount of collected statistics incrementally, so I personally have
> no problem with any plans.

Yeah. I'd like to add more items. But I think we will at most do the
above things by our manpower.

> >  - If not enough, what are any other statistics tasks which we should
> >    complete in year 5?
> 
> I believe we should first make some cleanups before considering any
> extensions.  I created some tickets in this area: #2843, #2883, #2884,
> #2781.  b10-stats is also generally not well tested (see #2781 for
> example).  I also believe it needs some refactoring, e.g., by breaking
> huge methods into manageable smaller ones (again, see #2781).  It's
> also currently quite fragile, naively propagating/ignoring error cases
> such as exceptions and die in a strange manner (see, e.g., #2636).

I'm agreed with including these cleanup tasks. But I think we should
prioritize these tasks. Should we decide which ticket to start
depending on how much it affects to the user? At this point of view, I
think #2884 is comparatively important.

#2843 and #2883 are redesigning tasks for the current python
statistics library. These might be problem when we try to extend the
library for another bind10 module's statistics.

I think #2781 might be related to #2636. To only suppressing stack
traces from b10-stats, it would be very easy as I commented on #2560.
We can fix this at #2781 or another ticket. However do we need to also
revise cc-session and msgq too if we try to fundamentally improve
#2636?

> Other types of cleanups are:
> - we should use 64-bit counters (I guess this will require changes to
>   msgq/cc session data structures).  32 bits are too small in this
>   modern world.
> - how to handle parameterized counters, such as per RR type/class
>   ones, and support them.

Thank you for suggestion. I think we might need a new ticket for the
first one.  However does the second one partially match #2792
(Implement per-RRtype statistics items)?

> > What do you think about this? Could you give your opinion?
> 
> Statistics for the resolver, although it may not be of your interest:-)

Definitely statistics for the resolver should be implemented. But I
think we should complete at first statistics of the authoritative
server rather than the resolver's ones.

Regards,

Naoki Kambe


More information about the bind10-dev mailing list