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.
|