On 06/07/2010 04:30 PM, Ken McDonell wrote:
> G'day Cornel,
>
> Thanks for the explanations. I understand better now.
>
> I'm just left with one question ....
>
> On Mon, 2010-06-07 at 14:50 -0500, Corneliu Boac wrote:
>
>> ...
>>
>>>
>>>
>>>> 4) I will monitor all requests (possible from multiple clients) and
>>>> refresh the data to accommodate the slowest pulling client.
>>>>
>>>>
>>> Sorry, I don't understand this at all ... "you" (being the pmda) cannot
>>> see the pmcd clients (as per my comment above), so who/what are these
>>> clients?
>>>
>>> In what sense is a client "slowest"?
>>>
>>>
>>
>> If there are multiple clients requesting the same data at intervals
>> longer than the refresh time, we will adjust the algorithm to not stop
>> pmclusterds push the data so we can satisfy the slowest client.
>> In example if we stop pmclusterds from pushing data when no request has
>> arrived for the last two values and then we receive a new request right
>> after that, we could adjust the algorithm to accomodate for slower rates
>> and let more pushed values waste before stopping pmclusterds.
>>
> I think this part is difficult. You cannot see the individual client
> request patterns, nor even how many clients there might be. And it is
> not possible to distinguish between a long fetch delta and one client
> stopping and later another client starting.
>
> I suspect you'd be better with some tuneable timeout that is applied
> globally to each metric, rather than trying to deduce when to stop the
> pmclusterds sending data based on the pattern of incoming requests.
> There could be an element of feedback to adjust this timeout based on
> the frequency of requests for information that is not available (because
> the pmclusterds have been stopped), but used to be available.
>
>
Hi Ken,
What you say makes sense and is a lot easier to implement.
So you think the proposed changes should work and I can start
implementing them?
Any suggestions, tips, etc?
Thank you,
Cornel.
|