add per second rate for timer sum and timer count #234

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants

keen99 commented Jan 8, 2013

add count_rate and sum_rate to timers - gives a built in per second rate for these.

I'm open to discussion on this one - I didn't add anything to the readme because count and sum aren't documented there at all yet.....

Also don't know if this change (which would only add new data for users who get it in an upgrade and should be non impacting, other than disk space/carbon load) should have a config to turn it on, or default it on and be able to turn it on, or or or...

open to discussion. but works and passes unit tests. should merge clean into my other PRs.

should note that sum_rate probably doesn't make a lot of sense for "timers" that are actually measurements of time.... but if you were using timers as (say) counters with more features.. I think count_rate still makes sense though since it gives you a rate of reporters for the interval...

Owner

mrtazz commented Jan 14, 2013

Are you using these stats for anything? I'm curious about the use case, since the different timer measurements are pretty detached from the StatsD flush interval. And I don't get at the moment what insights you could get from these?

keen99 commented Jan 14, 2013

we were playing around with some data that were not timers, but using timers to send the data because of the extra bits (90th, min/max, stddev, etc). we might normally just use counters, but we'd lose the extras.

but with switching from counter to timer, we lost the rate calculation....and unless I missed something, counter just takes counter@flush and divides by flush interval to get the per second rate.

So we applied that first to sum@flush - which makes timer sum and sum_rate match counter count and count_rate.

Next we were looking at the data and realized there's a new piece we can expose - since timers are actually a set of metrics, we can measure how many times the metric gets updated without a separate metric (as opposed to the value of the counter/timer), since we already figure out timer/count. so timer/count_rate seemed useful.

The specific use case was just a one off so far while we were running something for a few hours - but it seemed useful enough to make a feature (or an optional feature).

Owner

mrtazz commented Feb 19, 2013

Closing this since half of it already got implemented in #243. Going to add the sum rate based on the same calculation.

@mrtazz mrtazz closed this Feb 19, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment