← Back to team overview

graphite-dev team mailing list archive

Re: [Question #148357]: federated storage and complex wildcard targets = suboptimal

 

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

    Status: Open => Answered

chrismd proposed the following answer:
Hi Kevin, there is some complexity involved in the way the federated
storage works but it does sound a bit excessive in this case. What
version are you using?

I'd recommend giving trunk a try, or if you're patient, 0.9.8 in about 2
weeks or so. I added caching of find requests, which are a necessary
step in the rendering process. Barring that though, 11k http requests is
simply ridiculous for 14 graphs :). I'd be happy to help troubleshoot if
you still see this problem on the latest version. In any case though,
the best way to optimize your graphs is to store metrics that reflect
your rendering requests (just like you'd setup indicies in a relational
database that fit the queries you intend to run). In your case, if you
have 270 wsp files that are involved in a sumSeries used in many
requests, it would be optimal to compute the sum of these 270 metrics as
its own metric that can be used directly. In 0.9.8 there will be a new
carbon daemon, carbon-aggregator, that will give you the ability to
compute sum or average aggregate metrics based on individual metrics
matching specified patterns.

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