Situation description:

The data from the warpstor-server program continually streams into the
redis database where it is stored.  The data takes the form of method
entry timestamp, and length of time spent in the method.  The idea is
that, for example, clones-per-<time period> can be calculated by using
this data for the clone method call.

There are two things going on, as far as the snmp server is concerned, the
first is that it has to take this data and convert it into some kind of
number that can be represented as, for example, clones-per-<time period>.
The second is that the data in redis has to be managed as part of this
process.

The equation for figuring out the first item is not necessarily that
difficult, but is highly related to the second thing, which is more
complicated.  In theory, a time bracket can be arbitrarily decided upon,
and then all the data points that start and finish within that time
bracket can be counted, and an op-per-T number can be conjured up.

The second thing is a bit more tricky, at least in my mind.  How to manage
all the data.  On a busy system, there will be a lot of data pouring in.

Non-exhaustive list of thoughts:

Thought 1:
Should the snmp server try to come up with some soft of correlation scheme
between timestamps reported by warpstor-server program and timestamps
inside the snmp server program, and then query the data that falls in
between two of these correlated timestamps?  My guess is that the code
to create such a query to send to redis isn't that difficult, although
the code to come up with some sort of timestamp correlation scheme might
be much more so.  However, it's not clear to me that this will scale:
performing the query will take some processing time via the redis server.
On top of that, some sort of scheme to delete DEFINITLY old data has to
be concocted, because I don't think we can let the database grow forever
and just hope for the best.

Thought 2:
Have the snmp program just grab all the data (for a particular method)
available, and then do something smart with it to come up with a number,
and delete from the database all the data that was actually grabbed
(remember, there might/not be a continuous stream of new data coming
in), and somehow keep, internally, the data points from the grabbed data
that weren't included in the calculation of the reported number for some
sort of inclusion in the next go-round.  Or figure out which data points
were used in the calculation, and only delete those from the database.
Either way, this could potentially be some complicated code that takes a
while to develope and debug.  Not really possible in the current reigning
project estimate.

Thought 3:
Another possibility is to query the data in the database, delete
from the database what was retrieved, and take the duration times and
somehow calculate a running average number that represents something
like 'seconds-per-clone'.  I don't even know how how meaningful that
number would be, but then again I'm not sure I know how meaningful a
clones-per-T number would be, except on a very busy system.

Comments, ideas, suggestions?  I might be over thinking this, which would
mean that I missed something obvious, so if you're thinking 'well, he
must have thought of that, even though he did not mention it', go ahead
and say something just to be sure.