[
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16270598#comment-16270598
]
Alexey Kuznetsov edited comment on IGNITE-6846 at 11/29/17 11:09 AM:
---------------------------------------------------------------------
[~vkulichenko] Thanks for answers.
2.Assume, we invoked processor(read-only, not value is changed) on primary
node, on transactional cache. Right after that expiry policy got expired(ttl
equals CU.TTL_ZERO) and entry is removed. So 'invoke read-only' metric isn't
incremented. Should we increment 'total number of invocations' metric in this
case? I think no(moreover, no 'invoke*' metrics should be incremented)
4.For instance.If we update one key, in replicated atomic cache, entry
processor is invoked only once, on primary node. And then invocation result is
transfered by atomic update requests between backups(entry processor isn't
transfered).
So, may be we should increment only primary node's 'invoke *' metric ? While
leaving backup's metrics zero.
6.In ATOMIC caches regular 'remove' metric isn't incremented if cache is empty.
Whereas TRANSACTIONAL cache's 'remove' metric is incremented!
I think we should not increment it in this case, and should not increment
'invoke delete' metric if cache is empty. And file a bug on TRANSACTIONAL cache
'removal' metric calculation.
7. The following metrics going to be added into CacheMetrics :
{code:java}
/**
* The total number of cache invocations, caused update.
*
* @return The number of invocation updates.
*/
public long getCacheInvokeUpdates();
/**
* The total number of cache invocations, caused removal.
*
* @return The number of invocation removals.
*/
public long getCacheInvokeRemovals();
/**
* The total number of cache invocations, caused no updates.
*
* @return The number of read-only invocations.
*/
public long getCacheReadOnlyInvokes();
/**
* The total number of cache invocations.
*
* @return The number of cache invocations.
*/
public long getCacheInvokes();
/**
* The mean time to execute cache invokes.
*
* @return The time in µs.
*/
public long getAverageCacheInvokesTime();
/**
* So far, the minimum time to execute cache invokes.
*
* @return The time in µs.
*/
public long getMinCacheInvokesTime();
/**
* So far, the maximum time to execute cache invokes.
*
* @return The time in µs.
*/
public long getMaxCacheInvokesTime();
{code}
was (Author: alexey kuznetsov):
[~vkulichenko] Thanks for the answers.
2.Assume, we invoked processor(read-only, not value is changed) on primary
node, on transactional cache. Right after that expiry policy got expired(ttl
equals CU.TTL_ZERO) and entry is removed. So 'invoke read-only' metric isn't
incremented. Should we increment 'total number of invocations' metric in this
case? I think no(moreover, no 'invoke*' metrics should be incremented)
4.For instance.If we update one key, in replicated atomic cache, entry
processor is invoked only once, on primary node. And then invocation result is
transfered by atomic update requests between backups(entry processor isn't
transfered).
So, may be we should increment only primary node's 'invoke *' metric ? While
leaving backup's metrics zero.
6.In ATOMIC caches regular 'remove' metric isn't incremented if cache is empty.
Whereas TRANSACTIONAL cache's 'remove' metric is incremented!
I think we should not increment it in this case, and should not increment
'invoke delete' metric if cache is empty. And file a bug on TRANSACTIONAL cache
'removal' metric calculation.
7. The following metrics going to be added into CacheMetrics :
{code:java}
/**
* The total number of cache invocations, caused update.
*
* @return The number of invocation updates.
*/
public long getCacheInvokeUpdates();
/**
* The total number of cache invocations, caused removal.
*
* @return The number of invocation removals.
*/
public long getCacheInvokeRemovals();
/**
* The total number of cache invocations, caused no updates.
*
* @return The number of read-only invocations.
*/
public long getCacheReadOnlyInvokes();
/**
* The total number of cache invocations.
*
* @return The number of cache invocations.
*/
public long getCacheInvokes();
/**
* The mean time to execute cache invokes.
*
* @return The time in µs.
*/
public long getAverageCacheInvokesTime();
/**
* So far, the minimum time to execute cache invokes.
*
* @return The time in µs.
*/
public long getMinCacheInvokesTime();
/**
* So far, the maximum time to execute cache invokes.
*
* @return The time in µs.
*/
public long getMaxCacheInvokesTime();
{code}
> Add metrics for entry processor invocations
> -------------------------------------------
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Affects Versions: 2.3
> Reporter: Valentin Kulichenko
> Assignee: Alexey Kuznetsov
> Priority: Critical
> Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations
> like {{get}}, {{put}} and {{remove}}, but nothing for
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
