[
https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887990#comment-16887990
]
Andrey Gura edited comment on IGNITE-11927 at 7/18/19 2:07 PM:
---------------------------------------------------------------
[~NIzhikov]
> Can you, please, make a simple, pseudo-code example of your idea?
Caches, for example. Not pseudo-code, but list of action items.
On cache start or metrics enabling on cache:
- create metrics holder object.
- create MetricRegistry instance.
- register metrics in MetricRegistry.
- add MetricsRegistry in GridMetricManager.
On cache stop or metrics disabling for chache:
- remove MetricRegistry from GridMetricManager.
- assign null to metrics holder object reference.
> 1. If we have 5000 caches, Ignite structures already huge. Why do you think
> metrics bring a huge impact on GC?
Why we should ignore this impact if we can just avoid it without much effort?
> 2. All AtomicLong fields are created in previous versions of
> CacheMetricsImpl. MetricRegistry is the only addition we made with the new
> framework.
You are right. But this addition lead to some changes in design. It's good time
to improve implementation.
Also, I think it would be better design if MetricRegistry will be immutable. It
will lead to more clear code structure and behavior.
> Do we have some benchmarks or other descriptions of this issue?
No, we don't. But obviously all this objects in heap are not free.
was (Author: agura):
[~NIzhikov]
> Can you, please, make a simple, pseudo-code example of your idea?
Caches, for example. Not pseudo-code, but list of action items.
On cache start or metrics enabling on cache:
- create metrics holder object.
- create MetricRegistry instance.
- register metrics in MetricRegistry.
- add MetricsRegistry in GridMetricManager.
On cache stop or metrics disabling for chache:
- remove MetricRegistry from GridMetricManager.
- assign null to metrics holder object reference.
> 1. If we have 5000 caches, Ignite structures already huge. Why do you think
> metrics bring a huge impact on GC?
Why we should ignore this impact if we can just avoid it without much effort?
> 2. All AtomicLong fields are created in previous versions of
> CacheMetricsImpl. MetricRegistry is the only addition we made with the new
> framework.
You are right. But this addition lead to some changes in design. It's good time
to improve implementation.
> Do we have some benchmarks or other descriptions of this issue?
No, we don't. But obviously all this objects in heap are not free.
> [IEP-35] Add ability to enable\disable subset of metrics
> --------------------------------------------------------
>
> Key: IGNITE-11927
> URL: https://issues.apache.org/jira/browse/IGNITE-11927
> Project: Ignite
> Issue Type: Improvement
> Reporter: Nikolay Izhikov
> Assignee: Nikolay Izhikov
> Priority: Major
> Labels: IEP-35
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite should be able to:
> * Enable or disable an arbitrary subset of the metrics. User should be able
> to do it in runtime.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
