Re: Client Cache metrics API design discussion.

[Valentin Kulichenko]

Vladimir,

As I already suggested in the ticket [1], I think that by default we should
return metrics for the whole cluster. Now we collect them only from local
node, which is confusing, especially on the client. If one needs metrics
for one node or from subset of nodes, metrics(ClusterGroup) method can be
used.

So as for the size, I'm definitely for option 2.

Option 3 is more about 'getCachePuts()', but not 'getSIze()', no? Where do
we increment this counter - on the client or on the primary node? If on the
client, this metric will work just as you described when you get metrics
for a particular client using metrics(ClusterGroup).

Probably it also would be useful to add localMetrics() shortcut method.

[1] https://issues.apache.org/jira/browse/IGNITE-2483

-Val

On Fri, Feb 5, 2016 at 8:44 AM, Vladimir Ershov 
wrote:

> Igniters!
>
> Here is a handsome moment in our current cache metrics API, that begs for
> an improvement and due to it significancy assumed to be discussed
> communitywise. Current CacheMetrics interface is confusing for a case, when
> it is accessed from a client node.
> One of the typical question is:
> *what CacheMetrics#getSize should return on a client Node for a non-Near
> non-Local cache?*
> Here are some options:
>
>1. Zero. As it works now, it is just 0, since there is no entries on the
>client node.
>2. Amount of all entries for this cache across the cluster.
>3. Or, and here comes an interesting part, - amount of values which were
>fore.x. created through this client node, as it is useful for
>#getAveragePutTime.
>4.  Your variant?
>
> The same for the rest of the API: getCacheHits (0, cluster, client),
> getTxDhtCommitQueueSize (0, cluster, for client keys, UnsOpEx?).
>
> Assuming this point can give a good start for our discussion: there are
> use-cases, that demands metrics to be gathered for a client node
> separately, fore.x. user can measure latency between nodes, by comparing
> #getAveragePutTime on client and server side. Thus I consider reasonable to
> implement specific ClientCacheMetricsImpl with logic for client, but actual
> questions are: what should methods like getSize, getHits return? Is it
> necessary to support backward compatibility here for metrics API? Does the
> community think that it is reasonable to put our efforts to this task and
> that we want to support case for cache metrics on a client node?
>
> Thoughts?
>

Re: Client Cache metrics API design discussion.

[Dmitriy Setrakyan]

Agree. All metrics should return the data for the whole cache, unless
specifically specified otherwise by user.

D.

On Fri, Feb 5, 2016 at 10:56 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Vladimir,
>
> As I already suggested in the ticket [1], I think that by default we should
> return metrics for the whole cluster. Now we collect them only from local
> node, which is confusing, especially on the client. If one needs metrics
> for one node or from subset of nodes, metrics(ClusterGroup) method can be
> used.
>
> So as for the size, I'm definitely for option 2.
>
> Option 3 is more about 'getCachePuts()', but not 'getSIze()', no? Where do
> we increment this counter - on the client or on the primary node? If on the
> client, this metric will work just as you described when you get metrics
> for a particular client using metrics(ClusterGroup).
>
> Probably it also would be useful to add localMetrics() shortcut method.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-2483
>
> -Val
>
> On Fri, Feb 5, 2016 at 8:44 AM, Vladimir Ershov 
> wrote:
>
> > Igniters!
> >
> > Here is a handsome moment in our current cache metrics API, that begs for
> > an improvement and due to it significancy assumed to be discussed
> > communitywise. Current CacheMetrics interface is confusing for a case,
> when
> > it is accessed from a client node.
> > One of the typical question is:
> > *what CacheMetrics#getSize should return on a client Node for a non-Near
> > non-Local cache?*
> > Here are some options:
> >
> >1. Zero. As it works now, it is just 0, since there is no entries on
> the
> >client node.
> >2. Amount of all entries for this cache across the cluster.
> >3. Or, and here comes an interesting part, - amount of values which
> were
> >fore.x. created through this client node, as it is useful for
> >#getAveragePutTime.
> >4.  Your variant?
> >
> > The same for the rest of the API: getCacheHits (0, cluster, client),
> > getTxDhtCommitQueueSize (0, cluster, for client keys, UnsOpEx?).
> >
> > Assuming this point can give a good start for our discussion: there are
> > use-cases, that demands metrics to be gathered for a client node
> > separately, fore.x. user can measure latency between nodes, by comparing
> > #getAveragePutTime on client and server side. Thus I consider reasonable
> to
> > implement specific ClientCacheMetricsImpl with logic for client, but
> actual
> > questions are: what should methods like getSize, getHits return? Is it
> > necessary to support backward compatibility here for metrics API? Does
> the
> > community think that it is reasonable to put our efforts to this task and
> > that we want to support case for cache metrics on a client node?
> >
> > Thoughts?
> >
>