Hello!
Let me chime in to this discussion.
If we are doing any new metrics, please make sure that they are accessible.
I would expect that metrics are printed to console from time to time, at
least when they deviate from norm. It would also help if they are available
as Web Console screen, a sys
> but between to have something and have nothing i choose — something
We already have "something". put, get, etc. metrics. As I told early
it relatively useless. But the same metrics with histograms doesn't
add any value.
> i found 1 grid machine with very different io usage than others, «dig dee
>> And if we have two metrics that are triggered for the same then one of them
>> is useless.
> I don't understand what is the two metrics you are talking about.
Please, don't loose context. In your example it was checkpoint time
and some cache operation time.
> A business transaction includes w
>> Is it become slower or faster?
>
>Very correct question! User saw "cache put time" metric becomes x2
>bigger. Does it become slower or faster? Or we just put into the cache
>values that 4x bigger in size? Or all time before we put values
>locally and now we put values on remote nodes. Or our op
> And if we have two metrics that are triggered for the same then one of them
> is useless.
I don't understand what is the two metrics you are talking about.
I wrote about a single metric for a single cache operation.
> Obviously if you want know how fast or slow your business operation you must
> For example, the user saw «checkpoint time» metric becomes x2 bigger.
I just quote your words: " this is a trigger to make a deeper
investigation". And if we have two metrics that are triggered for the
same then one of them is useless.
> How it relates to business operations?
Why it should be
> It also will be visible on other metrics
How will it be visible?
For example, the user saw «checkpoint time» metric becomes x2 bigger.
How it relates to business operations? Is it become slower or faster?
What does it mean for an application performance?
On the other hand - if `PuTime` increas
> If a cache has some percent of the relatively slow transaction this is a
> trigger to make a deeper investigation.
It also will be visible on other metrics. So cache operations metrics
still useless because it transitive values.
>> 1. Measure some important internals (WAL operations, checkpoin
Hello, Andrey.
> Where the sense in this value? I explained why this metrics are relatively
> useless.
I don’t agree with you.
I believe they are not useless for a user.
And I try to explain why I think so.
> But user can't distinguish one transaction from another, so his knowledge
> doesn't m
> The goal of the proposed metrics is to measure whole cache operations
> behavior.
> It provides some kind of statistics(histograms) for it.
Nikolay, reformulating doesn't make metrics more meaningful. Seriously :)
> Yes, metrics will evaluate API call performance
And what? Where the sense in
Hello, Andrey.
The goal of the proposed metrics is to measure whole cache operations behavior.
It provides some kind of statistics(histograms) for it.
For more fine-grained analysis one will be use tracing or other «go deeper»
tools.
> > Measured for API calls on the caller node side
> Values wi
>From my point of view, Ignite should provide meaningful metrics for
internal components that could be useful for monitoring and analysis.
All suggested options are meaningless in a sense. Below I'll try
explain why.
>* `get`, `put`, `remove` time histograms. Measured for API calls on the caller
I think these metrics are useful.
I have prepared PR [1] for commit and rollback histograms. [2]
Nikolay, could you take a look, please?
If you do not mind, I will try to add affinity-nodes cache metrics:
>> * histograms that measure the time of processing `get`, `put`, `remove`,
>> `commit`, `r
I think they are very useful.
пн, 16 дек. 2019 г. в 10:51, Николай Ижиков :
> Hello, Alexei.
>
> Thanks for the link on the ticket, lableled it with the IEP-35 label.
> What do you think about proposed metrics set?
>
> > 16 дек. 2019 г., в 10:29, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
Hello, Alexei.
Thanks for the link on the ticket, lableled it with the IEP-35 label.
What do you think about proposed metrics set?
> 16 дек. 2019 г., в 10:29, Alexei Scherbakov
> написал(а):
>
> Nikolay,
>
> What about batch operations?
>
> For messages processing the ticket does exist and e
Nikolay,
What about batch operations?
For messages processing the ticket does exist and even has an
implementation from before new metrics API times [1]
[1] https://issues.apache.org/jira/browse/IGNITE-10418
пн, 16 дек. 2019 г. в 10:12, Николай Ижиков :
> Hello, Igniters.
>
> I want to provide
Hello, Igniters.
I want to provide the user answers to the following question: "How cache API
operations perform?"
It seems, we need to implements metrics for basic cache API operations like
get, put, remove for it.
I think we should provide the following metrics:
* `get`, `put`, `remove` tim
17 matches
Mail list logo
