ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Kuznetsov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations
Date Wed, 29 Nov 2017 14:26:00 GMT

    [ 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 2:25 PM:
--------------------------------------------------------------------

[~vkulichenko] Thanks for answers. I still have several questions :

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}

8.In partitioned cache with backup nodes. 
* If we perform read-only invoke operation, then 'read-only' metric on primary node is incremented,
while on other nodes its zero.
* If we perform update\remove invoke operation, then 'update'\'remove' metric on primary and
backup nodes is incremented, while on others its zero.




was (Author: alexey kuznetsov):
[~vkulichenko] Thanks for answers. I still have several questions :

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)

Mime
View raw message