Hi,
Dmitriy thanks for note, I will keep metrics IEP in mind.
Roman it sounds quite a straightforward approach. Moreover current cache
transactions follow it: there could be a number of invisible actions in
private workspace (e.g. creating and then deleting the same entry) but only
final changes are metered.
Also, I observed strange behavior for TRANSACTIONAL cache operations. For
following case metrics surprised me (numbers in comments):
public void testPutRemove() throws Exception {
cache.remove(1);
System.out.println(cache.metrics().getCacheRemovals()); // 1
cache.put(1, "a");
cache.remove(1);
System.out.println(cache.metrics().getCacheRemovals()); // 2
}
While for ATOMIC cache I see 0 and 1 which looks much better. And similar
effect is observed for "replace" operations.
Is it a bug? Do we have some document describing how metrics should be
counted?
2018-08-08 21:11 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> I think we should be updating the IEP with metrics specifications in
> parallel.
>
> D.
>
> On Wed, Aug 8, 2018, 05:32 Roman Kondakov <kondako...@mail.ru.invalid>
> wrote:
>
> > Hi Ivan!
> >
> > In my opinion we need to preserve the essence of the metrics: if we
> > didn't consider dirty writes as updates before MVCC implementation, we
> > also shouldn't count these writes in MVCC metrics implementation too.
> > So, I think we need to count only committed entries. But we can count
> > this dirty writes as additional metrics.
> >
> > Also additional metrics concerning MVCC could be:
> >
> > - Average count of the active transactions per snapshot
> >
> > - Average quantity of versions per key
> >
> >
> > --
> >
> > Roman Kondakov
> >
> >
> > On 07.08.2018 17:17, Павлухин Иван wrote:
> > > Hi Igniters,
> > >
> > > I am working on cache metrics support for caches with enabled MVCC. As
> > you
> > > may know, during MVCC transaction execution entry versions are written
> to
> > > storage right away (without deferring until commit). So, it is not
> > obvious
> > > for me if we should update writes count right away or defer it until
> > > commit. On one hand, MVCC entry version write is not "true" write until
> > > commit. On the other hand, it definitely changes the storage. How do we
> > > interpret write metrics in Ignite philosophy?
> > >
> > > Also, it seems that bunch of MVCC specific metrics could be
> introduced. I
> > > would like to collect some thoughts about it. Which such metrics come
> to
> > > your mind?
> > >
> >
> >
>
--
Best regards,
Ivan Pavlukhin
