>> 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
> 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
13 matches
Mail list logo
