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 Wed, 20 Sep 2017 17:38:20 GMT
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