| To: | "Frank Ch. Eigler" <fche@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [issue] pmwebd graphite api performance issue |
| From: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
| Date: | Tue, 28 Jul 2015 08:49:59 +1000 |
| Cc: | pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <y0mpp3d1bqq.fsf@xxxxxxxx> |
| References: | <a00f452763fd43f98eb5123d3ec0c3cf@xxxxxxxxxxxxxxxxxxxxxxxxx> <55B69826.7030103@xxxxxxxxxxxxxxxx> <y0mpp3d1bqq.fsf@xxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
On 28/07/15 08:23, Frank Ch. Eigler wrote: Thanks! More caching (whether within pmwebd or libpcp) would likely help this case. Will ponder it deeper once we have the problem child ^W archive in hand. Does not necessarily require any additional cacheing ... I was suggest an algorithmic change, from
traverse pmns
for each metric of interest found
get the metadata (including indom)
to
traverse pmns
salt away each metric of interest
foreach metric of interest
skip metric if already done
get metadata
process this _and_ all other metrics with the same indom
If an indom is common to N metrics this reduces the pmGetInDomArchive()
calls from N to 1 for all those metrics
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [pcp] [question] PCP UI FrontEnd, Ken McDonell |
|---|---|
| Next by Date: | Re: [pcp] qa/662 failing with python2.7, Nathan Scott |
| Previous by Thread: | Re: [issue] pmwebd graphite api performance issue, Frank Ch. Eigler |
| Next by Thread: | Re: [issue] pmwebd graphite api performance issue, Frank Ch. Eigler |
| Indexes: | [Date] [Thread] [Top] [All Lists] |