ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Gura <ag...@apache.org>
Subject Re: JCache time-based metrics
Date Thu, 21 Sep 2017 11:43:44 GMT
+1 for adding explanation to documentation.

On Thu, Sep 21, 2017 at 10:12 AM, Andrey Mashenkov
<andrey.mashenkov@gmail.com> wrote:
> Alex,
> I think we can just add an explanation of  meaningless of time-based metric
> for explicit transactions in documentation.
>
> 21 сент. 2017 г. 9:56 пользователь "Alexey Goncharuk" <
> alexey.goncharuk@gmail.com> написал:
>
> Well, a transactional cache still implements the JCache spec, so we need to
> provide these metrics with some meaningful semantics. Agree that mixing
> implicit and explicit txs will mess up the metrics, but I doubt we can do
> anything about it.
>
> 2017-09-20 20:38 GMT+03:00 Andrey Gura <agura@apache.org>:
>
>> Alexey,
>>
>> implicit transactions still can cause problems in metrics interpretation:
>>
>> - locks acquiring is still needed;
>> - metrics that taken in account for implicit transactions and missed
>> metrics for explicit transactions for the same cache still can
>> confuse.
>>
>> On Wed, Sep 20, 2017 at 6:02 PM, Alexey Goncharuk
>> <alexey.goncharuk@gmail.com> wrote:
>> > Agree with Andrey here. Probably, we can keep existing JCache metrics
> for
>> > implicit transactions, but we should design a whole new interface to
>> handle
>> > transaction metrics, including various transaction stages, such as lock
>> > acquisition, prepare and commit phases. In my opinion, this is the only
>> way
>> > to have unambiguous metrics in the product.
>> >
>> > 2017-09-20 17:58 GMT+03:00 Andrey Gura <agura@apache.org>:
>> >
>> >> Slava and Igniters,
>> >>
>> >> Do you have any suggestions about described problem?
>> >>
>> >> From my point of view JCache API metrics specification has a number of
>> >> statements that can't be uniquely treated by Ignite user because of
>> >> implementations details. Most obvious problems here are related with
>> >> transactions that are distributed and have some properties that affect
>> >> their behaviour. Pessimistic transactions during entry modification
>> >> will enlist entry into transaction (read operation), acquire lock (it
>> >> can take some time if another transaction is already lock owner) and
>> >> eventually write modified entry into the cache. Where is modification
>> >> operation start? What if after cache.put() and before commit user
>> >> performs some time consuming operation? For optimistic transactions
>> >> still there is lock waiting time that affects metrics.
>> >>
>> >> So JCache API metrics are useless for transactions and could confuse
>> >> user. It seems that we shouldn't support JCache metrics at all in case
>> >> of transactional operations. May be we can offer another metrics that
>> >> could be more useful.
>> >>
>> >> Thoughts?
>> >>
>> >> On Tue, Sep 19, 2017 at 8:19 PM, Вячеслав Коптилин
>> >> <slava.koptilin@gmail.com> wrote:
>> >> > I'd want to make a new attempt to discuss JCache metrics, especially
>> >> > time-based metrics.
>> >> > As discussed earlier (
>> >> > http://apache-ignite-developers.2346864.n4.nabble.
>> >> com/Cache-Metrics-tt19699.html
>> >> > ),
>> >> > there are two approaches (and at first glance, the second one is
>> >> > preferable):
>> >> >     #1 Node that starts some operation is responsible for updating
> the
>> >> > cache metrics.
>> >> >     #2 Primary node (node that actually executes a request)
>> >> >
>> >> > I have one question/concern about time-based metrics for
> transactional
>> >> > caches.
>> >> > The JCache specification does not have definition like a transaction,
>> >> > partitioned cache etc,
>> >> > and, therefore, cannot provide convenience and clear understanding
>> about
>> >> > the average time for that case.
>> >> >
>> >> > Let's assume, for example, we have the following code:
>> >> >
>> >> >         try (Transaction tx =
>> >> > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
>> >> > TransactionIsolation.READ_COMMITTED)) {
>> >> >             value = cache.get(key);
>> >> >             // calculate new value for the given key
>> >> >             ...
>> >> >             cache.put(key, new_value);     // (1)
>> >> >
>> >> >             // some additional operations
>> >> >
>> >> >             // another update
>> >> >             value = cache.get(key);        // (2)
>> >> >             ...
>> >> >             cache.put(key, new_value);
>> >> >
>> >> >             tx.commit();                   // (3)
>> >> >         }
>> >> >
>> >> > What is the average time for write operation? Is it a time needed for
>> >> > enlisting an entry in the transaction scope, acquiring locks,
>> committing
>> >> > changes?
>> >> > For that particular case, current implementation accumulates both
>> timings
>> >> > (1)&(2) on the local node during performing put operation, but
> 'write'
>> >> > counter is updated only once on data node during commit phase.
>> >> > I think this behavior is not obvious at least.
>> >> >
>> >> > Thanks,
>> >> > Slava.
>> >>
>>

Mime
View raw message