graphite-dev team mailing list archive

[chrismd <question148357@xxxxxxxxxxxxxxxxxxxxx>]

Question #148357 on Graphite changed:
https://answers.launchpad.net/graphite/+question/148357

chrismd proposed the following answer:
The find requests do use wildcards (if not something might be wrong),
but the render requests to retrieve the actual datapoints are still done
separately. This is something I've been working on in another branch and
will likely be fixed in 0.9.9. Could you post an access log snippet so I
can verify it is the expected behavior?

As far as calculating summaries, carbon-aggregator will be able to do
sums for you but I haven't put in a derivative calculation yet. It's
definitely feasible to add that though. What I usually do when I've got
lots of individual counter metrics is to sum up all the counters into a
summary counter and then apply nonNegativeDerivative() to that at render
time. Summing at storage time vs at render time will give you the same
end result. However calculating the derivatives before/after the sum can
affect the result if you use nonNegativeDerivative. That is, if you do
what I described where you store sums of the counters and then apply
nonNegativeDerivative you can end up under-reporting any datapoint that
includes a reset counter. To ensure it is always accurate you would need
to calculate the individual non-negative derivatives and sum those.

There is nothing wrong with using rendering functions, that is what
they're there for and they generally don't add much overhead, but any
graphing request that involves a large number of metrics will always
take a performance hit compared to one that uses fewer summary metrics,
so any summarization that can be done at storage time optimizes your
graphing performance.

-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.