pcp
[Top] [All Lists]

Re: [issue] pmwebd graphite api performance issue

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [issue] pmwebd graphite api performance issue
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Mon, 27 Jul 2015 18:23:09 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <55B69826.7030103@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Tue, 28 Jul 2015 06:44:22 +1000")
References: <a00f452763fd43f98eb5123d3ec0c3cf@xxxxxxxxxxxxxxxxxxxxxxxxx> <55B69826.7030103@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
Ken McDonell <kenj@xxxxxxxxxxxxxxxx> writes:

>> The part about *pmGetInDomArchive* is kind of bothering me, since it
>> looks like it's spending most of its time in that method.
>>
>> Any thoughts on how to improve my experience ?
>
> Can you send me one of the archives?

Me too me too! :-)  

We haven't encountered this particular hanging fruit before.


> A quick look at the pmwebd source suggests that it is processing the
> metadata in the pmns traversal callback ... if there are lots of
> metrics over the _same_ instance domain, and that instance domain is
> large, then this will call pmGetInDomArchive O(# metrics with the same
> indom) instead of O(1).
>
> If my crude analysis is correct (this is not my code), then this looks
> to be a candidate for some serious code optimization.
> [...]

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.


- FChE

<Prev in Thread] Current Thread [Next in Thread>