Hi Dirk,
thanks for your comments.
On 31 Jan 2009, at 12:40, Dirk-Willem van Gulik wrote:
Paul Davis wrote:
>> The way that stats are calculated currently with the dependent
>> variable being time could cause some issues in implementing more
>> statistics. With my extremely limited knowledge of stats I think
>> moving that to be dependent on the number of requests might be
better.
Code looks awesome. For reference, they're storing the last N samples
with each time point over a given time period. Ie, they store the
current counter values once a second.
Eh - do you really want to build RRDtool/cacti/nagios/zenoss/mrtg
like capabilities in your database ?
No.
I'd say - focus on getting the data out (ideally as _counters_) and
let the monitoring tools figure out the rest. They know their
polling intervals and what not (some dynimically adjust) and can
figure out how to sample, calculate rates, do stats and what not.
And can have fairly refined windowing techniques to aggregate (e.g.
rrdtool).
So do not try to make a stats module - try to make a module that
output the data on which you can base your starts :).
I.e. when you can have:
database_opened counter
database_closed counter
you can work out 1) rate of open/close, 2) the number currently open
and do all sorts of post processing. Whereas a float giving you some
rate over some unknown window is not nearly as useful.
We have pure counters and raw data for all the tools. After all,
this was done after your spec which asked for some aggregate
values, so we put it in. The aggregates are well defined: 900
second window, 1 second resolution. We don't plan to make
this any fancier, just add more counters.
Cheers
Jan
--
