Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Ilya Kasnacheev]

Hello!

Readme.io uses blue book :)

https://apacheignite.readme.io/docs/performance-tips

I was thinking of something along a blue circle with `i' in it, for
information items.

Regards,
--
Ilya Kasnacheev


ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <[hidden email]>:

> > Search does not seem to work.
> It uses mockups right now, but it should be ready when the docs are
> released.
>
> > I can see that note blocks are just annotated with "Note." Can we have
> some
> > image there?
> Do you have a preference as to which image you would like to see there?
>
> -Artem
>
> On 19.08.2020 17:37, Ilya Kasnacheev wrote:
> > Hello!
> >
> > Search does not seem to work. Are we going to have a proper search
> results
> > page? It is often the case that there's none.
> >
> > I can see that note blocks are just annotated with "Note." Can we have
> some
> > image there? Example is
> > http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
> >
> > Regards,
>

[Alexey Plekhanov]

Hello, guys!

We finally have some benchmark results. Looks like there is more than one
commit with a performance drop. Detected drops for those commits only
slightly higher than measurement error, so it was hard to find them and we
are not completely sure we found them all and found them right.

Drops detected:
2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
implementation)
2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is refactored
in order to detect registration of message with the same direct type)

The total drop we have on our environment - 7-8% and perhaps there is
something else here (benchmarks still in progress, I will write if we find
more suspected commits).

Ivan Artiukhov, can you please recheck mentioned above commits on your
environment?


чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <[hidden email]>:

> Hello!
>
> Readme.io uses blue book :)
>
> https://apacheignite.readme.io/docs/performance-tips
>
> I was thinking of something along a blue circle with `i' in it, for
> information items.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <[hidden email]>:
>
> > > Search does not seem to work.
> > It uses mockups right now, but it should be ready when the docs are
> > released.
> >
> > > I can see that note blocks are just annotated with "Note." Can we have
> > some
> > > image there?
> > Do you have a preference as to which image you would like to see there?
> >
> > -Artem
> >
> > On 19.08.2020 17:37, Ilya Kasnacheev wrote:
> > > Hello!
> > >
> > > Search does not seem to work. Are we going to have a proper search
> > results
> > > page? It is often the case that there's none.
> > >
> > > I can see that note blocks are just annotated with "Note." Can we have
> > some
> > > image there? Example is
> > > http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
> > >
> > > Regards,
> >
>

[dmagda]

Alex,

Thanks for sending an update. The drop is quite big. What are the types of
benchmarks you are observing the degradation for (atomic puts,
transactions, sql, etc.)?

Let us know if any help by particular committers is required.

-
Denis


On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <[hidden email]>
wrote:

> Hello, guys!
>
> We finally have some benchmark results. Looks like there is more than one
> commit with a performance drop. Detected drops for those commits only
> slightly higher than measurement error, so it was hard to find them and we
> are not completely sure we found them all and found them right.
>
> Drops detected:
> 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
> implementation)
> 2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is refactored
> in order to detect registration of message with the same direct type)
>
> The total drop we have on our environment - 7-8% and perhaps there is
> something else here (benchmarks still in progress, I will write if we find
> more suspected commits).
>
> Ivan Artiukhov, can you please recheck mentioned above commits on your
> environment?
>
>
> чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <[hidden email]>:
>
> > Hello!
> >
> > Readme.io uses blue book :)
> >
> > https://apacheignite.readme.io/docs/performance-tips
> >
> > I was thinking of something along a blue circle with `i' in it, for
> > information items.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <[hidden email]
> >:
> >
> > > > Search does not seem to work.
> > > It uses mockups right now, but it should be ready when the docs are
> > > released.
> > >
> > > > I can see that note blocks are just annotated with "Note." Can we
> have
> > > some
> > > > image there?
> > > Do you have a preference as to which image you would like to see there?
> > >
> > > -Artem
> > >
> > > On 19.08.2020 17:37, Ilya Kasnacheev wrote:
> > > > Hello!
> > > >
> > > > Search does not seem to work. Are we going to have a proper search
> > > results
> > > > page? It is often the case that there's none.
> > > >
> > > > I can see that note blocks are just annotated with "Note." Can we
> have
> > > some
> > > > image there? Example is
> > > > http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
> > > >
> > > > Regards,
> > >
> >
>

[Alexey Plekhanov]

Denis,

Currently, we are running mostly IgnitePutTxImplicitBenchmark without
persistence. For other benchmarks drop is lower and it's harder to find
problematic commit.

ср, 26 авг. 2020 г. в 17:34, Denis Magda <[hidden email]>:

> Alex,
>
> Thanks for sending an update. The drop is quite big. What are the types of
> benchmarks you are observing the degradation for (atomic puts,
> transactions, sql, etc.)?
>
> Let us know if any help by particular committers is required.
>
> -
> Denis
>
>
> On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <[hidden email]>
> wrote:
>
> > Hello, guys!
> >
> > We finally have some benchmark results. Looks like there is more than one
> > commit with a performance drop. Detected drops for those commits only
> > slightly higher than measurement error, so it was hard to find them and
> we
> > are not completely sure we found them all and found them right.
> >
> > Drops detected:
> > 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
> > implementation)
> > 2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is
> refactored
> > in order to detect registration of message with the same direct type)
> >
> > The total drop we have on our environment - 7-8% and perhaps there is
> > something else here (benchmarks still in progress, I will write if we
> find
> > more suspected commits).
> >
> > Ivan Artiukhov, can you please recheck mentioned above commits on your
> > environment?
> >
> >
> > чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <[hidden email]
> >:
> >
> > > Hello!
> > >
> > > Readme.io uses blue book :)
> > >
> > > https://apacheignite.readme.io/docs/performance-tips
> > >
> > > I was thinking of something along a blue circle with `i' in it, for
> > > information items.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <
> [hidden email]
> > >:
> > >
> > > > > Search does not seem to work.
> > > > It uses mockups right now, but it should be ready when the docs are
> > > > released.
> > > >
> > > > > I can see that note blocks are just annotated with "Note." Can we
> > have
> > > > some
> > > > > image there?
> > > > Do you have a preference as to which image you would like to see
> there?
> > > >
> > > > -Artem
> > > >
> > > > On 19.08.2020 17:37, Ilya Kasnacheev wrote:
> > > > > Hello!
> > > > >
> > > > > Search does not seem to work. Are we going to have a proper search
> > > > results
> > > > > page? It is often the case that there's none.
> > > > >
> > > > > I can see that note blocks are just annotated with "Note." Can we
> > have
> > > > some
> > > > > image there? Example is
> > > > > http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
> > > > >
> > > > > Regards,
> > > >
> > >
> >
>

[Artem Budnikov]

Hi everyone,

We published the draft of Ignite 2.9 documentation on the Apache Ignite
web-site. The docs are available via the following link:

https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker

Alex,

Is there an estimate for the release date?

-Artem

On 26.08.2020 17:47, Alex Plehanov wrote:

> Denis,
>
> Currently, we are running mostly IgnitePutTxImplicitBenchmark without
> persistence. For other benchmarks drop is lower and it's harder to find
> problematic commit.
>
> ср, 26 авг. 2020 г. в 17:34, Denis Magda <[hidden email]>:
>
>> Alex,
>>
>> Thanks for sending an update. The drop is quite big. What are the types of
>> benchmarks you are observing the degradation for (atomic puts,
>> transactions, sql, etc.)?
>>
>> Let us know if any help by particular committers is required.
>>
>> -
>> Denis
>>
>>
>> On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <[hidden email]>
>> wrote:
>>
>>> Hello, guys!
>>>
>>> We finally have some benchmark results. Looks like there is more than one
>>> commit with a performance drop. Detected drops for those commits only
>>> slightly higher than measurement error, so it was hard to find them and
>> we
>>> are not completely sure we found them all and found them right.
>>>
>>> Drops detected:
>>> 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
>>> implementation)
>>> 2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is
>> refactored
>>> in order to detect registration of message with the same direct type)
>>>
>>> The total drop we have on our environment - 7-8% and perhaps there is
>>> something else here (benchmarks still in progress, I will write if we
>> find
>>> more suspected commits).
>>>
>>> Ivan Artiukhov, can you please recheck mentioned above commits on your
>>> environment?
>>>
>>>
>>> чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <[hidden email]
>>> :
>>>
>>>> Hello!
>>>>
>>>> Readme.io uses blue book :)
>>>>
>>>> https://apacheignite.readme.io/docs/performance-tips
>>>>
>>>> I was thinking of something along a blue circle with `i' in it, for
>>>> information items.
>>>>
>>>> Regards,
>>>> --
>>>> Ilya Kasnacheev
>>>>
>>>>
>>>> ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <
>> [hidden email]
>>>> :
>>>>
>>>>>> Search does not seem to work.
>>>>> It uses mockups right now, but it should be ready when the docs are
>>>>> released.
>>>>>
>>>>>> I can see that note blocks are just annotated with "Note." Can we
>>> have
>>>>> some
>>>>>> image there?
>>>>> Do you have a preference as to which image you would like to see
>> there?
>>>>> -Artem
>>>>>
>>>>> On 19.08.2020 17:37, Ilya Kasnacheev wrote:
>>>>>> Hello!
>>>>>>
>>>>>> Search does not seem to work. Are we going to have a proper search
>>>>> results
>>>>>> page? It is often the case that there's none.
>>>>>>
>>>>>> I can see that note blocks are just annotated with "Note." Can we
>>> have
>>>>> some
>>>>>> image there? Example is
>>>>>> http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
>>>>>>
>>>>>> Regards,

[dmagda]

Looks beautiful and easy to use, thanks, Artem! Could you please add the
following copyright to the footer of the pages?

*© 2020 The Apache Software Foundation.*
*Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are
either registered trademarks or trademarks of The Apache Software
Foundation. *
*Privacy Policy*

-
Denis


On Thu, Aug 27, 2020 at 5:20 AM Artem Budnikov <[hidden email]>
wrote:

> Hi everyone,
>
> We published the draft of Ignite 2.9 documentation on the Apache Ignite
> web-site. The docs are available via the following link:
>
> https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker
>
> Alex,
>
> Is there an estimate for the release date?
>
> -Artem
>
> On 26.08.2020 17:47, Alex Plehanov wrote:
> > Denis,
> >
> > Currently, we are running mostly IgnitePutTxImplicitBenchmark without
> > persistence. For other benchmarks drop is lower and it's harder to find
> > problematic commit.
> >
> > ср, 26 авг. 2020 г. в 17:34, Denis Magda <[hidden email]>:
> >
> >> Alex,
> >>
> >> Thanks for sending an update. The drop is quite big. What are the types
> of
> >> benchmarks you are observing the degradation for (atomic puts,
> >> transactions, sql, etc.)?
> >>
> >> Let us know if any help by particular committers is required.
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <[hidden email]
> >
> >> wrote:
> >>
> >>> Hello, guys!
> >>>
> >>> We finally have some benchmark results. Looks like there is more than
> one
> >>> commit with a performance drop. Detected drops for those commits only
> >>> slightly higher than measurement error, so it was hard to find them and
> >> we
> >>> are not completely sure we found them all and found them right.
> >>>
> >>> Drops detected:
> >>> 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
> >>> implementation)
> >>> 2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is
> >> refactored
> >>> in order to detect registration of message with the same direct type)
> >>>
> >>> The total drop we have on our environment - 7-8% and perhaps there is
> >>> something else here (benchmarks still in progress, I will write if we
> >> find
> >>> more suspected commits).
> >>>
> >>> Ivan Artiukhov, can you please recheck mentioned above commits on your
> >>> environment?
> >>>
> >>>
> >>> чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <
> [hidden email]
> >>> :
> >>>
> >>>> Hello!
> >>>>
> >>>> Readme.io uses blue book :)
> >>>>
> >>>> https://apacheignite.readme.io/docs/performance-tips
> >>>>
> >>>> I was thinking of something along a blue circle with `i' in it, for
> >>>> information items.
> >>>>
> >>>> Regards,
> >>>> --
> >>>> Ilya Kasnacheev
> >>>>
> >>>>
> >>>> ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <
> >> [hidden email]
> >>>> :
> >>>>
> >>>>>> Search does not seem to work.
> >>>>> It uses mockups right now, but it should be ready when the docs are
> >>>>> released.
> >>>>>
> >>>>>> I can see that note blocks are just annotated with "Note." Can we
> >>> have
> >>>>> some
> >>>>>> image there?
> >>>>> Do you have a preference as to which image you would like to see
> >> there?
> >>>>> -Artem
> >>>>>
> >>>>> On 19.08.2020 17:37, Ilya Kasnacheev wrote:
> >>>>>> Hello!
> >>>>>>
> >>>>>> Search does not seem to work. Are we going to have a proper search
> >>>>> results
> >>>>>> page? It is often the case that there's none.
> >>>>>>
> >>>>>> I can see that note blocks are just annotated with "Note." Can we
> >>> have
> >>>>> some
> >>>>>> image there? Example is
> >>>>>> http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
> >>>>>>
> >>>>>> Regards,
>

[Alexey Plekhanov]

Guys,

We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it
locally) and got the same performance as on 2.8.1

IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
hot paths, it's clear why we have performance drop here.

IGNITE-12568 (MessageFactory refactoring) - switch/case block was
refactored to an array of message suppliers. The message factory is on the
hot path, which explains why this commit has an impact on total
performance.
I've checked JIT assembly output, done some JMH microbenchmarks, and found
that old implementation of MessageFactory.create() about 30-35% faster than
the new one. The reason - approach with switch/case can effectively inline
message creation code, but with an array of suppliers relatively heavy
"invokeinterface" cannot be skipped. I've tried to rewrite the code using
an abstract class for suppliers instead of an interface (to
replace "invokeinterface" with the "invokevirtual"), but it gives back only
10% of method performance and in this case, code looks ugly (lambdas can't
be used). Currently, I can't find any more ways to optimize the current
approach (except return to the switch/case block). Andrey Gura, as the
author of IGNITE-12568, maybe you have some ideas about optimization?

Perhaps we should revert IGNITE-12568, but there are some metrics already
created, which can't be rewritten using old message factory implementation
(IGNITE-12756). Guys, WDYT?

пт, 28 авг. 2020 г. в 01:52, Denis Magda <[hidden email]>:

> Looks beautiful and easy to use, thanks, Artem! Could you please add the
> following copyright to the footer of the pages?
>
> *© 2020 The Apache Software Foundation.*
> *Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are
> either registered trademarks or trademarks of The Apache Software
> Foundation. *
> *Privacy Policy*
>
> -
> Denis
>
>
> On Thu, Aug 27, 2020 at 5:20 AM Artem Budnikov <
> [hidden email]> wrote:
>
>> Hi everyone,
>>
>> We published the draft of Ignite 2.9 documentation on the Apache Ignite
>> web-site. The docs are available via the following link:
>>
>> https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker
>>
>> Alex,
>>
>> Is there an estimate for the release date?
>>
>> -Artem
>>
>> On 26.08.2020 17:47, Alex Plehanov wrote:
>> > Denis,
>> >
>> > Currently, we are running mostly IgnitePutTxImplicitBenchmark without
>> > persistence. For other benchmarks drop is lower and it's harder to find
>> > problematic commit.
>> >
>> > ср, 26 авг. 2020 г. в 17:34, Denis Magda <[hidden email]>:
>> >
>> >> Alex,
>> >>
>> >> Thanks for sending an update. The drop is quite big. What are the
>> types of
>> >> benchmarks you are observing the degradation for (atomic puts,
>> >> transactions, sql, etc.)?
>> >>
>> >> Let us know if any help by particular committers is required.
>> >>
>> >> -
>> >> Denis
>> >>
>> >>
>> >> On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <
>> [hidden email]>
>> >> wrote:
>> >>
>> >>> Hello, guys!
>> >>>
>> >>> We finally have some benchmark results. Looks like there is more than
>> one
>> >>> commit with a performance drop. Detected drops for those commits only
>> >>> slightly higher than measurement error, so it was hard to find them
>> and
>> >> we
>> >>> are not completely sure we found them all and found them right.
>> >>>
>> >>> Drops detected:
>> >>> 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
>> >>> implementation)
>> >>> 2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is
>> >> refactored
>> >>> in order to detect registration of message with the same direct type)
>> >>>
>> >>> The total drop we have on our environment - 7-8% and perhaps there is
>> >>> something else here (benchmarks still in progress, I will write if we
>> >> find
>> >>> more suspected commits).
>> >>>
>> >>> Ivan Artiukhov, can you please recheck mentioned above commits on your
>> >>> environment?
>> >>>
>> >>>
>> >>> чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <
>> [hidden email]
>> >>> :
>> >>>
>> >>>> Hello!
>> >>>>
>> >>>> Readme.io uses blue book :)
>> >>>>
>> >>>> https://apacheignite.readme.io/docs/performance-tips
>> >>>>
>> >>>> I was thinking of something along a blue circle with `i' in it, for
>> >>>> information items.
>> >>>>
>> >>>> Regards,
>> >>>> --
>> >>>> Ilya Kasnacheev
>> >>>>
>> >>>>
>> >>>> ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <
>> >> [hidden email]
>> >>>> :
>> >>>>
>> >>>>>> Search does not seem to work.
>> >>>>> It uses mockups right now, but it should be ready when the docs are
>> >>>>> released.
>> >>>>>
>> >>>>>> I can see that note blocks are just annotated with "Note." Can we
>> >>> have
>> >>>>> some
>> >>>>>> image there?
>> >>>>> Do you have a preference as to which image you would like to see
>> >> there?
>> >>>>> -Artem
>> >>>>>
>> >>>>> On 19.08.2020 17:37, Ilya Kasnacheev wrote:
>> >>>>>> Hello!
>> >>>>>>
>> >>>>>> Search does not seem to work. Are we going to have a proper search
>> >>>>> results
>> >>>>>> page? It is often the case that there's none.
>> >>>>>>
>> >>>>>> I can see that note blocks are just annotated with "Note." Can we
>> >>> have
>> >>>>> some
>> >>>>>> image there? Example is
>> >>>>>> http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
>> >>>>>>
>> >>>>>> Regards,
>>
>

[Anton Kalashnikov]

Hi Guys,

As I understand we will be merging some tickets to release. May I suggest also add ticket [1] to 2.9 release.

There are not a lot of changes in code but It's a critical fix for the ability to launch ignite in lamba on Azure(There are not any workaround).

So if nobody minds let's merge it to 2.9.

[1] https://issues.apache.org/jira/browse/IGNITE-13013

-- 
Best regards,
Anton Kalashnikov



28.08.2020, 11:16, "Alex Plehanov" <[hidden email]>:

> Guys,
>
> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it
> locally) and got the same performance as on 2.8.1
>
> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
> hot paths, it's clear why we have performance drop here.
>
> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> refactored to an array of message suppliers. The message factory is on the
> hot path, which explains why this commit has an impact on total
> performance.
> I've checked JIT assembly output, done some JMH microbenchmarks, and found
> that old implementation of MessageFactory.create() about 30-35% faster than
> the new one. The reason - approach with switch/case can effectively inline
> message creation code, but with an array of suppliers relatively heavy
> "invokeinterface" cannot be skipped. I've tried to rewrite the code using
> an abstract class for suppliers instead of an interface (to
> replace "invokeinterface" with the "invokevirtual"), but it gives back only
> 10% of method performance and in this case, code looks ugly (lambdas can't
> be used). Currently, I can't find any more ways to optimize the current
> approach (except return to the switch/case block). Andrey Gura, as the
> author of IGNITE-12568, maybe you have some ideas about optimization?
>
> Perhaps we should revert IGNITE-12568, but there are some metrics already
> created, which can't be rewritten using old message factory implementation
> (IGNITE-12756). Guys, WDYT?
>
> пт, 28 авг. 2020 г. в 01:52, Denis Magda <[hidden email]>:
>
>>  Looks beautiful and easy to use, thanks, Artem! Could you please add the
>>  following copyright to the footer of the pages?
>>
>>  *© 2020 The Apache Software Foundation.*
>>  *Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are
>>  either registered trademarks or trademarks of The Apache Software
>>  Foundation. *
>>  *Privacy Policy*
>>
>>  -
>>  Denis
>>
>>  On Thu, Aug 27, 2020 at 5:20 AM Artem Budnikov <
>>  [hidden email]> wrote:
>>
>>>  Hi everyone,
>>>
>>>  We published the draft of Ignite 2.9 documentation on the Apache Ignite
>>>  web-site. The docs are available via the following link:
>>>
>>>  https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker
>>>
>>>  Alex,
>>>
>>>  Is there an estimate for the release date?
>>>
>>>  -Artem
>>>
>>>  On 26.08.2020 17:47, Alex Plehanov wrote:
>>>  > Denis,
>>>  >
>>>  > Currently, we are running mostly IgnitePutTxImplicitBenchmark without
>>>  > persistence. For other benchmarks drop is lower and it's harder to find
>>>  > problematic commit.
>>>  >
>>>  > ср, 26 авг. 2020 г. в 17:34, Denis Magda <[hidden email]>:
>>>  >
>>>  >> Alex,
>>>  >>
>>>  >> Thanks for sending an update. The drop is quite big. What are the
>>>  types of
>>>  >> benchmarks you are observing the degradation for (atomic puts,
>>>  >> transactions, sql, etc.)?
>>>  >>
>>>  >> Let us know if any help by particular committers is required.
>>>  >>
>>>  >> -
>>>  >> Denis
>>>  >>
>>>  >>
>>>  >> On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <
>>>  [hidden email]>
>>>  >> wrote:
>>>  >>
>>>  >>> Hello, guys!
>>>  >>>
>>>  >>> We finally have some benchmark results. Looks like there is more than
>>>  one
>>>  >>> commit with a performance drop. Detected drops for those commits only
>>>  >>> slightly higher than measurement error, so it was hard to find them
>>>  and
>>>  >> we
>>>  >>> are not completely sure we found them all and found them right.
>>>  >>>
>>>  >>> Drops detected:
>>>  >>> 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
>>>  >>> implementation)
>>>  >>> 2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is
>>>  >> refactored
>>>  >>> in order to detect registration of message with the same direct type)
>>>  >>>
>>>  >>> The total drop we have on our environment - 7-8% and perhaps there is
>>>  >>> something else here (benchmarks still in progress, I will write if we
>>>  >> find
>>>  >>> more suspected commits).
>>>  >>>
>>>  >>> Ivan Artiukhov, can you please recheck mentioned above commits on your
>>>  >>> environment?
>>>  >>>
>>>  >>>
>>>  >>> чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <
>>>  [hidden email]
>>>  >>> :
>>>  >>>
>>>  >>>> Hello!
>>>  >>>>
>>>  >>>> Readme.io uses blue book :)
>>>  >>>>
>>>  >>>> https://apacheignite.readme.io/docs/performance-tips
>>>  >>>>
>>>  >>>> I was thinking of something along a blue circle with `i' in it, for
>>>  >>>> information items.
>>>  >>>>
>>>  >>>> Regards,
>>>  >>>> --
>>>  >>>> Ilya Kasnacheev
>>>  >>>>
>>>  >>>>
>>>  >>>> ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <
>>>  >> [hidden email]
>>>  >>>> :
>>>  >>>>
>>>  >>>>>> Search does not seem to work.
>>>  >>>>> It uses mockups right now, but it should be ready when the docs are
>>>  >>>>> released.
>>>  >>>>>
>>>  >>>>>> I can see that note blocks are just annotated with "Note." Can we
>>>  >>> have
>>>  >>>>> some
>>>  >>>>>> image there?
>>>  >>>>> Do you have a preference as to which image you would like to see
>>>  >> there?
>>>  >>>>> -Artem
>>>  >>>>>
>>>  >>>>> On 19.08.2020 17:37, Ilya Kasnacheev wrote:
>>>  >>>>>> Hello!
>>>  >>>>>>
>>>  >>>>>> Search does not seem to work. Are we going to have a proper search
>>>  >>>>> results
>>>  >>>>>> page? It is often the case that there's none.
>>>  >>>>>>
>>>  >>>>>> I can see that note blocks are just annotated with "Note." Can we
>>>  >>> have
>>>  >>>>> some
>>>  >>>>>> image there? Example is
>>>  >>>>>> http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
>>>  >>>>>>
>>>  >>>>>> Regards,

[Ivan Daschinsky]

Artem, in ignite 2.9 a way to build C++ for linux/mac os x was changed
(autotools to cmake). As an author of this change, I want to contribute in
documentation.
As far as I understand, now it should be done through PR to specific
repository. Could you please help me with this?

пт, 28 авг. 2020 г. в 16:33, Anton Kalashnikov <[hidden email]>:

> Hi Guys,
>
> As I understand we will be merging some tickets to release. May I suggest
> also add ticket [1] to 2.9 release.
>
> There are not a lot of changes in code but It's a critical fix for the
> ability to launch ignite in lamba on Azure(There are not any workaround).
>
> So if nobody minds let's merge it to 2.9.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-13013
>
> --
> Best regards,
> Anton Kalashnikov
>
>
>
> 28.08.2020, 11:16, "Alex Plehanov" <[hidden email]>:
> > Guys,
> >
> > We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted
> it
> > locally) and got the same performance as on 2.8.1
> >
> > IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
> > hot paths, it's clear why we have performance drop here.
> >
> > IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> > refactored to an array of message suppliers. The message factory is on
> the
> > hot path, which explains why this commit has an impact on total
> > performance.
> > I've checked JIT assembly output, done some JMH microbenchmarks, and
> found
> > that old implementation of MessageFactory.create() about 30-35% faster
> than
> > the new one. The reason - approach with switch/case can effectively
> inline
> > message creation code, but with an array of suppliers relatively heavy
> > "invokeinterface" cannot be skipped. I've tried to rewrite the code using
> > an abstract class for suppliers instead of an interface (to
> > replace "invokeinterface" with the "invokevirtual"), but it gives back
> only
> > 10% of method performance and in this case, code looks ugly (lambdas
> can't
> > be used). Currently, I can't find any more ways to optimize the current
> > approach (except return to the switch/case block). Andrey Gura, as the
> > author of IGNITE-12568, maybe you have some ideas about optimization?
> >
> > Perhaps we should revert IGNITE-12568, but there are some metrics already
> > created, which can't be rewritten using old message factory
> implementation
> > (IGNITE-12756). Guys, WDYT?
> >
> > пт, 28 авг. 2020 г. в 01:52, Denis Magda <[hidden email]>:
> >
> >>  Looks beautiful and easy to use, thanks, Artem! Could you please add
> the
> >>  following copyright to the footer of the pages?
> >>
> >>  *© 2020 The Apache Software Foundation.*
> >>  *Apache, Apache Ignite, the Apache feather and the Apache Ignite logo
> are
> >>  either registered trademarks or trademarks of The Apache Software
> >>  Foundation. *
> >>  *Privacy Policy*
> >>
> >>  -
> >>  Denis
> >>
> >>  On Thu, Aug 27, 2020 at 5:20 AM Artem Budnikov <
> >>  [hidden email]> wrote:
> >>
> >>>  Hi everyone,
> >>>
> >>>  We published the draft of Ignite 2.9 documentation on the Apache
> Ignite
> >>>  web-site. The docs are available via the following link:
> >>>
> >>>
> https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker
> >>>
> >>>  Alex,
> >>>
> >>>  Is there an estimate for the release date?
> >>>
> >>>  -Artem
> >>>
> >>>  On 26.08.2020 17:47, Alex Plehanov wrote:
> >>>  > Denis,
> >>>  >
> >>>  > Currently, we are running mostly IgnitePutTxImplicitBenchmark
> without
> >>>  > persistence. For other benchmarks drop is lower and it's harder to
> find
> >>>  > problematic commit.
> >>>  >
> >>>  > ср, 26 авг. 2020 г. в 17:34, Denis Magda <[hidden email]>:
> >>>  >
> >>>  >> Alex,
> >>>  >>
> >>>  >> Thanks for sending an update. The drop is quite big. What are the
> >>>  types of
> >>>  >> benchmarks you are observing the degradation for (atomic puts,
> >>>  >> transactions, sql, etc.)?
> >>>  >>
> >>>  >> Let us know if any help by particular committers is required.
> >>>  >>
> >>>  >> -
> >>>  >> Denis
> >>>  >>
> >>>  >>
> >>>  >> On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <
> >>>  [hidden email]>
> >>>  >> wrote:
> >>>  >>
> >>>  >>> Hello, guys!
> >>>  >>>
> >>>  >>> We finally have some benchmark results. Looks like there is more
> than
> >>>  one
> >>>  >>> commit with a performance drop. Detected drops for those commits
> only
> >>>  >>> slightly higher than measurement error, so it was hard to find
> them
> >>>  and
> >>>  >> we
> >>>  >>> are not completely sure we found them all and found them right.
> >>>  >>>
> >>>  >>> Drops detected:
> >>>  >>> 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing: initial
> >>>  >>> implementation)
> >>>  >>> 2-3% drop on commit 65c30ec6947 (IGNITE-12568 MessageFactory is
> >>>  >> refactored
> >>>  >>> in order to detect registration of message with the same direct
> type)
> >>>  >>>
> >>>  >>> The total drop we have on our environment - 7-8% and perhaps
> there is
> >>>  >>> something else here (benchmarks still in progress, I will write
> if we
> >>>  >> find
> >>>  >>> more suspected commits).
> >>>  >>>
> >>>  >>> Ivan Artiukhov, can you please recheck mentioned above commits on
> your
> >>>  >>> environment?
> >>>  >>>
> >>>  >>>
> >>>  >>> чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <
> >>>  [hidden email]
> >>>  >>> :
> >>>  >>>
> >>>  >>>> Hello!
> >>>  >>>>
> >>>  >>>> Readme.io uses blue book :)
> >>>  >>>>
> >>>  >>>> https://apacheignite.readme.io/docs/performance-tips
> >>>  >>>>
> >>>  >>>> I was thinking of something along a blue circle with `i' in it,
> for
> >>>  >>>> information items.
> >>>  >>>>
> >>>  >>>> Regards,
> >>>  >>>> --
> >>>  >>>> Ilya Kasnacheev
> >>>  >>>>
> >>>  >>>>
> >>>  >>>> ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <
> >>>  >> [hidden email]
> >>>  >>>> :
> >>>  >>>>
> >>>  >>>>>> Search does not seem to work.
> >>>  >>>>> It uses mockups right now, but it should be ready when the docs
> are
> >>>  >>>>> released.
> >>>  >>>>>
> >>>  >>>>>> I can see that note blocks are just annotated with "Note." Can
> we
> >>>  >>> have
> >>>  >>>>> some
> >>>  >>>>>> image there?
> >>>  >>>>> Do you have a preference as to which image you would like to see
> >>>  >> there?
> >>>  >>>>> -Artem
> >>>  >>>>>
> >>>  >>>>> On 19.08.2020 17:37, Ilya Kasnacheev wrote:
> >>>  >>>>>> Hello!
> >>>  >>>>>>
> >>>  >>>>>> Search does not seem to work. Are we going to have a proper
> search
> >>>  >>>>> results
> >>>  >>>>>> page? It is often the case that there's none.
> >>>  >>>>>>
> >>>  >>>>>> I can see that note blocks are just annotated with "Note." Can
> we
> >>>  >>> have
> >>>  >>>>> some
> >>>  >>>>>> image there? Example is
> >>>  >>>>>> http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
> >>>  >>>>>>
> >>>  >>>>>> Regards,
>

--
Sincerely yours, Ivan Daschinskiy

[Artem Budnikov]

Hi Ivan,

The documentation for Ignite 2.9 is kept here:
https://github.com/apache/ignite/tree/IGNITE-7595/docs

There is a readme file with instructions. You can make a pull request to
this branch. However, the installation instruction for Ignite C++ hasn't
been created yet. If you want, you can create the "Setting up Ignite for
C++" page by copying this [1] from readme.io and updating it with your
changes.

-Artem

[1]
https://apacheignite-cpp.readme.io/docs/getting-started-1#building-from-source

On 31.08.2020 09:43, Ivan Daschinsky wrote:

> Artem, in ignite 2.9 a way to build C++ for linux/mac os x was changed
> (autotools to cmake). As an author of this change, I want to
> contribute in documentation.
> As far as I understand, now it should be done through PR to specific
> repository. Could you please help me with this?
>
> пт, 28 авг. 2020 г. в 16:33, Anton Kalashnikov <[hidden email]
> <mailto:[hidden email]>>:
>
>     Hi Guys,
>
>     As I understand we will be merging some tickets to release. May I
>     suggest also add ticket [1] to 2.9 release.
>
>     There are not a lot of changes in code but It's a critical fix for
>     the ability to launch ignite in lamba on Azure(There are not any
>     workaround).
>
>     So if nobody minds let's merge it to 2.9.
>
>     [1] https://issues.apache.org/jira/browse/IGNITE-13013
>     <https://issues.apache.org/jira/browse/IGNITE-13013>
>
>     --
>     Best regards,
>     Anton Kalashnikov
>
>
>
>     28.08.2020, 11:16, "Alex Plehanov" <[hidden email]
>     <mailto:[hidden email]>>:
>     > Guys,
>     >
>     > We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568
>     (reverted it
>     > locally) and got the same performance as on 2.8.1
>     >
>     > IGNITE-13060 (Tracing) - some code was added to hot paths, to
>     trace these
>     > hot paths, it's clear why we have performance drop here.
>     >
>     > IGNITE-12568 (MessageFactory refactoring) - switch/case block was
>     > refactored to an array of message suppliers. The message factory
>     is on the
>     > hot path, which explains why this commit has an impact on total
>     > performance.
>     > I've checked JIT assembly output, done some JMH microbenchmarks,
>     and found
>     > that old implementation of MessageFactory.create() about 30-35%
>     faster than
>     > the new one. The reason - approach with switch/case can
>     effectively inline
>     > message creation code, but with an array of suppliers relatively
>     heavy
>     > "invokeinterface" cannot be skipped. I've tried to rewrite the
>     code using
>     > an abstract class for suppliers instead of an interface (to
>     > replace "invokeinterface" with the "invokevirtual"), but it
>     gives back only
>     > 10% of method performance and in this case, code looks ugly
>     (lambdas can't
>     > be used). Currently, I can't find any more ways to optimize the
>     current
>     > approach (except return to the switch/case block). Andrey Gura,
>     as the
>     > author of IGNITE-12568, maybe you have some ideas about
>     optimization?
>     >
>     > Perhaps we should revert IGNITE-12568, but there are some
>     metrics already
>     > created, which can't be rewritten using old message factory
>     implementation
>     > (IGNITE-12756). Guys, WDYT?
>     >
>     > пт, 28 авг. 2020 г. в 01:52, Denis Magda <[hidden email]
>     <mailto:[hidden email]>>:
>     >
>     >>  Looks beautiful and easy to use, thanks, Artem! Could you
>     please add the
>     >>  following copyright to the footer of the pages?
>     >>
>     >>  *© 2020 The Apache Software Foundation.*
>     >>  *Apache, Apache Ignite, the Apache feather and the Apache
>     Ignite logo are
>     >>  either registered trademarks or trademarks of The Apache Software
>     >>  Foundation. *
>     >>  *Privacy Policy*
>     >>
>     >>  -
>     >>  Denis
>     >>
>     >>  On Thu, Aug 27, 2020 at 5:20 AM Artem Budnikov <
>     >> [hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>
>     >>>  Hi everyone,
>     >>>
>     >>>  We published the draft of Ignite 2.9 documentation on the
>     Apache Ignite
>     >>>  web-site. The docs are available via the following link:
>     >>>
>     >>>
>     https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker
>     <https://ignite.apache.org/docs/2.9.0/installation/installing-using-docker>
>     >>>
>     >>>  Alex,
>     >>>
>     >>>  Is there an estimate for the release date?
>     >>>
>     >>>  -Artem
>     >>>
>     >>>  On 26.08.2020 17:47, Alex Plehanov wrote:
>     >>>  > Denis,
>     >>>  >
>     >>>  > Currently, we are running mostly
>     IgnitePutTxImplicitBenchmark without
>     >>>  > persistence. For other benchmarks drop is lower and it's
>     harder to find
>     >>>  > problematic commit.
>     >>>  >
>     >>>  > ср, 26 авг. 2020 г. в 17:34, Denis Magda <[hidden email]
>     <mailto:[hidden email]>>:
>     >>>  >
>     >>>  >> Alex,
>     >>>  >>
>     >>>  >> Thanks for sending an update. The drop is quite big. What
>     are the
>     >>>  types of
>     >>>  >> benchmarks you are observing the degradation for (atomic puts,
>     >>>  >> transactions, sql, etc.)?
>     >>>  >>
>     >>>  >> Let us know if any help by particular committers is required.
>     >>>  >>
>     >>>  >> -
>     >>>  >> Denis
>     >>>  >>
>     >>>  >>
>     >>>  >> On Wed, Aug 26, 2020 at 12:26 AM Alex Plehanov <
>     >>> [hidden email] <mailto:[hidden email]>>
>     >>>  >> wrote:
>     >>>  >>
>     >>>  >>> Hello, guys!
>     >>>  >>>
>     >>>  >>> We finally have some benchmark results. Looks like there
>     is more than
>     >>>  one
>     >>>  >>> commit with a performance drop. Detected drops for those
>     commits only
>     >>>  >>> slightly higher than measurement error, so it was hard to
>     find them
>     >>>  and
>     >>>  >> we
>     >>>  >>> are not completely sure we found them all and found them
>     right.
>     >>>  >>>
>     >>>  >>> Drops detected:
>     >>>  >>> 2-3% drop on commit 99b0e0143e0 (IGNITE-13060 Tracing:
>     initial
>     >>>  >>> implementation)
>     >>>  >>> 2-3% drop on commit 65c30ec6947 (IGNITE-12568
>     MessageFactory is
>     >>>  >> refactored
>     >>>  >>> in order to detect registration of message with the same
>     direct type)
>     >>>  >>>
>     >>>  >>> The total drop we have on our environment - 7-8% and
>     perhaps there is
>     >>>  >>> something else here (benchmarks still in progress, I will
>     write if we
>     >>>  >> find
>     >>>  >>> more suspected commits).
>     >>>  >>>
>     >>>  >>> Ivan Artiukhov, can you please recheck mentioned above
>     commits on your
>     >>>  >>> environment?
>     >>>  >>>
>     >>>  >>>
>     >>>  >>> чт, 20 авг. 2020 г. в 11:43, Ilya Kasnacheev <
>     >>> [hidden email] <mailto:[hidden email]>
>     >>>  >>> :
>     >>>  >>>
>     >>>  >>>> Hello!
>     >>>  >>>>
>     >>>  >>>> Readme.io uses blue book :)
>     >>>  >>>>
>     >>>  >>>> https://apacheignite.readme.io/docs/performance-tips
>     <https://apacheignite.readme.io/docs/performance-tips>
>     >>>  >>>>
>     >>>  >>>> I was thinking of something along a blue circle with `i'
>     in it, for
>     >>>  >>>> information items.
>     >>>  >>>>
>     >>>  >>>> Regards,
>     >>>  >>>> --
>     >>>  >>>> Ilya Kasnacheev
>     >>>  >>>>
>     >>>  >>>>
>     >>>  >>>> ср, 19 авг. 2020 г. в 18:29, Artem Budnikov <
>     >>>  >> [hidden email]
>     <mailto:[hidden email]>
>     >>>  >>>> :
>     >>>  >>>>
>     >>>  >>>>>> Search does not seem to work.
>     >>>  >>>>> It uses mockups right now, but it should be ready when
>     the docs are
>     >>>  >>>>> released.
>     >>>  >>>>>
>     >>>  >>>>>> I can see that note blocks are just annotated with
>     "Note." Can we
>     >>>  >>> have
>     >>>  >>>>> some
>     >>>  >>>>>> image there?
>     >>>  >>>>> Do you have a preference as to which image you would
>     like to see
>     >>>  >> there?
>     >>>  >>>>> -Artem
>     >>>  >>>>>
>     >>>  >>>>> On 19.08.2020 17:37, Ilya Kasnacheev wrote:
>     >>>  >>>>>> Hello!
>     >>>  >>>>>>
>     >>>  >>>>>> Search does not seem to work. Are we going to have a
>     proper search
>     >>>  >>>>> results
>     >>>  >>>>>> page? It is often the case that there's none.
>     >>>  >>>>>>
>     >>>  >>>>>> I can see that note blocks are just annotated with
>     "Note." Can we
>     >>>  >>> have
>     >>>  >>>>> some
>     >>>  >>>>>> image there? Example is
>     >>>  >>>>>>
>     http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning
>     <http://64.227.57.229/docs/2.9.0/persistence/persistence-tuning>
>     >>>  >>>>>>
>     >>>  >>>>>> Regards,
>
>
>
> --
> Sincerely yours, Ivan Daschinskiy

[Alexey Goncharuk]

пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <[hidden email]>:

> Guys,
>
> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it
> locally) and got the same performance as on 2.8.1
>
> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
> hot paths, it's clear why we have performance drop here.
>
> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> refactored to an array of message suppliers. The message factory is on the
> hot path, which explains why this commit has an impact on total
> performance.
> I've checked JIT assembly output, done some JMH microbenchmarks, and found
> that old implementation of MessageFactory.create() about 30-35% faster than
> the new one. The reason - approach with switch/case can effectively inline
> message creation code, but with an array of suppliers relatively heavy
> "invokeinterface" cannot be skipped. I've tried to rewrite the code using
> an abstract class for suppliers instead of an interface (to
> replace "invokeinterface" with the "invokevirtual"), but it gives back only
> 10% of method performance and in this case, code looks ugly (lambdas can't
> be used). Currently, I can't find any more ways to optimize the current
> approach (except return to the switch/case block). Andrey Gura, as the
> author of IGNITE-12568, maybe you have some ideas about optimization?
>
> Perhaps we should revert IGNITE-12568, but there are some metrics already
> created, which can't be rewritten using old message factory implementation
> (IGNITE-12756). Guys, WDYT?
>

Alexey,

I see that IGNITE-12756 (metrics improvements) is already released in
Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite
2.9. Let's revert both IGNITE-12568 and whichever new metrics created for
2.9 that depend on the new message factory to unblock the release and deal
with the optimizations in 2.10?

[Alexey Goncharuk]

Alexey,

While investigating, I found that IGNITE-12568 has an incorrect fix version
and is actually present in ignite-2.8.1 branch [1], so it cannot be the
source of the drop against 2.8.1.

P.S. Looks like we need to enforce a more accurate work with fix versions
or develop some sort of tooling to verify the fix versions.

--AG

[1]
https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34

пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <[hidden email]>:

> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <[hidden email]>:
>
>> Guys,
>>
>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it
>> locally) and got the same performance as on 2.8.1
>>
>> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
>> hot paths, it's clear why we have performance drop here.
>>
>> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
>> refactored to an array of message suppliers. The message factory is on the
>> hot path, which explains why this commit has an impact on total
>> performance.
>> I've checked JIT assembly output, done some JMH microbenchmarks, and found
>> that old implementation of MessageFactory.create() about 30-35% faster
>> than
>> the new one. The reason - approach with switch/case can effectively inline
>> message creation code, but with an array of suppliers relatively heavy
>> "invokeinterface" cannot be skipped. I've tried to rewrite the code using
>> an abstract class for suppliers instead of an interface (to
>> replace "invokeinterface" with the "invokevirtual"), but it gives back
>> only
>> 10% of method performance and in this case, code looks ugly (lambdas can't
>> be used). Currently, I can't find any more ways to optimize the current
>> approach (except return to the switch/case block). Andrey Gura, as the
>> author of IGNITE-12568, maybe you have some ideas about optimization?
>>
>> Perhaps we should revert IGNITE-12568, but there are some metrics already
>> created, which can't be rewritten using old message factory implementation
>> (IGNITE-12756). Guys, WDYT?
>>
>
> Alexey,
>
> I see that IGNITE-12756 (metrics improvements) is already released in
> Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite
> 2.9. Let's revert both IGNITE-12568 and whichever new metrics created for
> 2.9 that depend on the new message factory to unblock the release and deal
> with the optimizations in 2.10?
>

[Nikolay Izhikov-2]

Hello, Igniters.

Let’s include in the 2.9 release IGNITE-12718 [1]
This is a closed scope feature of the python thin client.
It was requested by some of our users.

[1] https://github.com/apache/ignite/commit/baf8c673c41a1790ef0a244862e6abfbd4eadbf5

> 31 авг. 2020 г., в 13:25, Alexey Goncharuk <[hidden email]> написал(а):
>
> Alexey,
>
> While investigating, I found that IGNITE-12568 has an incorrect fix version
> and is actually present in ignite-2.8.1 branch [1], so it cannot be the
> source of the drop against 2.8.1.
>
> P.S. Looks like we need to enforce a more accurate work with fix versions
> or develop some sort of tooling to verify the fix versions.
>
> --AG
>
> [1]
> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
>
> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <[hidden email]>:
>
>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <[hidden email]>:
>>
>>> Guys,
>>>
>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it
>>> locally) and got the same performance as on 2.8.1
>>>
>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
>>> hot paths, it's clear why we have performance drop here.
>>>
>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
>>> refactored to an array of message suppliers. The message factory is on the
>>> hot path, which explains why this commit has an impact on total
>>> performance.
>>> I've checked JIT assembly output, done some JMH microbenchmarks, and found
>>> that old implementation of MessageFactory.create() about 30-35% faster
>>> than
>>> the new one. The reason - approach with switch/case can effectively inline
>>> message creation code, but with an array of suppliers relatively heavy
>>> "invokeinterface" cannot be skipped. I've tried to rewrite the code using
>>> an abstract class for suppliers instead of an interface (to
>>> replace "invokeinterface" with the "invokevirtual"), but it gives back
>>> only
>>> 10% of method performance and in this case, code looks ugly (lambdas can't
>>> be used). Currently, I can't find any more ways to optimize the current
>>> approach (except return to the switch/case block). Andrey Gura, as the
>>> author of IGNITE-12568, maybe you have some ideas about optimization?
>>>
>>> Perhaps we should revert IGNITE-12568, but there are some metrics already
>>> created, which can't be rewritten using old message factory implementation
>>> (IGNITE-12756). Guys, WDYT?
>>>
>>
>> Alexey,
>>
>> I see that IGNITE-12756 (metrics improvements) is already released in
>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite
>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics created for
>> 2.9 that depend on the new message factory to unblock the release and deal
>> with the optimizations in 2.10?
>>

[Alexey Plekhanov]

Alexey, sorry, I wrongly interpreted our benchmark results. Actually, we
were looking for a drop using bi-sect in the range between e6a7f93 (first
commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last commit in
the 2.9 branch). And we found these two problematic commits.

Perhaps only IGNITE-13060 (Tracing) is responsible for a drop between 2.8.1
and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted IGNITE-13060 now
and performance looks the same)

Ticket IGNITE-12568 (MessageFactory refactoring) is not related to drop
between 2.8.1 and 2.9, but still has some performance problem, and we can
win back IGNITE-13060 drop by this ticket.

Do we need more investigation on IGNITE-13060 or we leave it as is?

What should we do with IGNITE-12568 (MessageFactory refactoring)?

пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk <[hidden email]>:

> Alexey,
>
> While investigating, I found that IGNITE-12568 has an incorrect fix
> version and is actually present in ignite-2.8.1 branch [1], so it cannot be
> the source of the drop against 2.8.1.
>
> P.S. Looks like we need to enforce a more accurate work with fix versions
> or develop some sort of tooling to verify the fix versions.
>
> --AG
>
> [1]
> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
>
> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <[hidden email]
> >:
>
>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <[hidden email]>:
>>
>>> Guys,
>>>
>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted
>>> it
>>> locally) and got the same performance as on 2.8.1
>>>
>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
>>> hot paths, it's clear why we have performance drop here.
>>>
>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
>>> refactored to an array of message suppliers. The message factory is on
>>> the
>>> hot path, which explains why this commit has an impact on total
>>> performance.
>>> I've checked JIT assembly output, done some JMH microbenchmarks, and
>>> found
>>> that old implementation of MessageFactory.create() about 30-35% faster
>>> than
>>> the new one. The reason - approach with switch/case can effectively
>>> inline
>>> message creation code, but with an array of suppliers relatively heavy
>>> "invokeinterface" cannot be skipped. I've tried to rewrite the code using
>>> an abstract class for suppliers instead of an interface (to
>>> replace "invokeinterface" with the "invokevirtual"), but it gives back
>>> only
>>> 10% of method performance and in this case, code looks ugly (lambdas
>>> can't
>>> be used). Currently, I can't find any more ways to optimize the current
>>> approach (except return to the switch/case block). Andrey Gura, as the
>>> author of IGNITE-12568, maybe you have some ideas about optimization?
>>>
>>> Perhaps we should revert IGNITE-12568, but there are some metrics already
>>> created, which can't be rewritten using old message factory
>>> implementation
>>> (IGNITE-12756). Guys, WDYT?
>>>
>>
>> Alexey,
>>
>> I see that IGNITE-12756 (metrics improvements) is already released in
>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite
>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics created for
>> 2.9 that depend on the new message factory to unblock the release and deal
>> with the optimizations in 2.10?
>>
>

[Alexey Goncharuk]

Alexey, thanks, got it. I am not sure we can optimize anything out of the
message factory with suppliers (at least I have no ideas right now), so
most likely the only move here is to switch back to the switch approach
somehow preserving the metrics part. Probably, inlining the Ignite messages
to the IgniteMessageFactoryImpl should do the trick. Let me explore the
code a bit.

P.S. I am surprised by the impact this part makes for the performance.
Message creation is indeed on the hot path, but a single virtual call
should not make that much of a difference given the amount of other work
happening during the message processing.

пн, 31 авг. 2020 г. в 18:33, Alex Plehanov <[hidden email]>:

> Alexey, sorry, I wrongly interpreted our benchmark results. Actually, we
> were looking for a drop using bi-sect in the range between e6a7f93 (first
> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last commit in
> the 2.9 branch). And we found these two problematic commits.
>
> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop between
> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted IGNITE-13060
> now and performance looks the same)
>
> Ticket IGNITE-12568 (MessageFactory refactoring) is not related to drop
> between 2.8.1 and 2.9, but still has some performance problem, and we can
> win back IGNITE-13060 drop by this ticket.
>
> Do we need more investigation on IGNITE-13060 or we leave it as is?
>
> What should we do with IGNITE-12568 (MessageFactory refactoring)?
>
> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk <[hidden email]
> >:
>
>> Alexey,
>>
>> While investigating, I found that IGNITE-12568 has an incorrect fix
>> version and is actually present in ignite-2.8.1 branch [1], so it cannot be
>> the source of the drop against 2.8.1.
>>
>> P.S. Looks like we need to enforce a more accurate work with fix versions
>> or develop some sort of tooling to verify the fix versions.
>>
>> --AG
>>
>> [1]
>> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
>>
>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <[hidden email]
>> >:
>>
>>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <[hidden email]>:
>>>
>>>> Guys,
>>>>
>>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted
>>>> it
>>>> locally) and got the same performance as on 2.8.1
>>>>
>>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace
>>>> these
>>>> hot paths, it's clear why we have performance drop here.
>>>>
>>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
>>>> refactored to an array of message suppliers. The message factory is on
>>>> the
>>>> hot path, which explains why this commit has an impact on total
>>>> performance.
>>>> I've checked JIT assembly output, done some JMH microbenchmarks, and
>>>> found
>>>> that old implementation of MessageFactory.create() about 30-35% faster
>>>> than
>>>> the new one. The reason - approach with switch/case can effectively
>>>> inline
>>>> message creation code, but with an array of suppliers relatively heavy
>>>> "invokeinterface" cannot be skipped. I've tried to rewrite the code
>>>> using
>>>> an abstract class for suppliers instead of an interface (to
>>>> replace "invokeinterface" with the "invokevirtual"), but it gives back
>>>> only
>>>> 10% of method performance and in this case, code looks ugly (lambdas
>>>> can't
>>>> be used). Currently, I can't find any more ways to optimize the current
>>>> approach (except return to the switch/case block). Andrey Gura, as the
>>>> author of IGNITE-12568, maybe you have some ideas about optimization?
>>>>
>>>> Perhaps we should revert IGNITE-12568, but there are some metrics
>>>> already
>>>> created, which can't be rewritten using old message factory
>>>> implementation
>>>> (IGNITE-12756). Guys, WDYT?
>>>>
>>>
>>> Alexey,
>>>
>>> I see that IGNITE-12756 (metrics improvements) is already released in
>>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite
>>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics created for
>>> 2.9 that depend on the new message factory to unblock the release and deal
>>> with the optimizations in 2.10?
>>>
>>

[Maxim Muzafarov]

Alexey,

I propose to include [1] issue to the 2.9 release. Since this issue is
related to the new master key change functionality which haven't been
released yet I think it will be safe to cherry-pick commit to the
release branch.

[1] https://issues.apache.org/jira/browse/IGNITE-13390

On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov <[hidden email]> wrote:

>
> Hello, Igniters.
>
> Alexey, please, include one more Python thin client fix [1] into the 2.9 release
> It fixes kinda major issue - "Python client returns fields in wrong order since the 2 row when fields_count>10"
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12809
> [2] https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
>
> > 31 авг. 2020 г., в 19:23, Alexey Goncharuk <[hidden email]> написал(а):
> >
> > Alexey, thanks, got it. I am not sure we can optimize anything out of the
> > message factory with suppliers (at least I have no ideas right now), so
> > most likely the only move here is to switch back to the switch approach
> > somehow preserving the metrics part. Probably, inlining the Ignite messages
> > to the IgniteMessageFactoryImpl should do the trick. Let me explore the
> > code a bit.
> >
> > P.S. I am surprised by the impact this part makes for the performance.
> > Message creation is indeed on the hot path, but a single virtual call
> > should not make that much of a difference given the amount of other work
> > happening during the message processing.
> >
> > пн, 31 авг. 2020 г. в 18:33, Alex Plehanov <[hidden email]>:
> >
> >> Alexey, sorry, I wrongly interpreted our benchmark results. Actually, we
> >> were looking for a drop using bi-sect in the range between e6a7f93 (first
> >> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last commit in
> >> the 2.9 branch). And we found these two problematic commits.
> >>
> >> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop between
> >> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted IGNITE-13060
> >> now and performance looks the same)
> >>
> >> Ticket IGNITE-12568 (MessageFactory refactoring) is not related to drop
> >> between 2.8.1 and 2.9, but still has some performance problem, and we can
> >> win back IGNITE-13060 drop by this ticket.
> >>
> >> Do we need more investigation on IGNITE-13060 or we leave it as is?
> >>
> >> What should we do with IGNITE-12568 (MessageFactory refactoring)?
> >>
> >> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk <[hidden email]
> >>> :
> >>
> >>> Alexey,
> >>>
> >>> While investigating, I found that IGNITE-12568 has an incorrect fix
> >>> version and is actually present in ignite-2.8.1 branch [1], so it cannot be
> >>> the source of the drop against 2.8.1.
> >>>
> >>> P.S. Looks like we need to enforce a more accurate work with fix versions
> >>> or develop some sort of tooling to verify the fix versions.
> >>>
> >>> --AG
> >>>
> >>> [1]
> >>> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
> >>>
> >>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <[hidden email]
> >>>> :
> >>>
> >>>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <[hidden email]>:
> >>>>
> >>>>> Guys,
> >>>>>
> >>>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted
> >>>>> it
> >>>>> locally) and got the same performance as on 2.8.1
> >>>>>
> >>>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace
> >>>>> these
> >>>>> hot paths, it's clear why we have performance drop here.
> >>>>>
> >>>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> >>>>> refactored to an array of message suppliers. The message factory is on
> >>>>> the
> >>>>> hot path, which explains why this commit has an impact on total
> >>>>> performance.
> >>>>> I've checked JIT assembly output, done some JMH microbenchmarks, and
> >>>>> found
> >>>>> that old implementation of MessageFactory.create() about 30-35% faster
> >>>>> than
> >>>>> the new one. The reason - approach with switch/case can effectively
> >>>>> inline
> >>>>> message creation code, but with an array of suppliers relatively heavy
> >>>>> "invokeinterface" cannot be skipped. I've tried to rewrite the code
> >>>>> using
> >>>>> an abstract class for suppliers instead of an interface (to
> >>>>> replace "invokeinterface" with the "invokevirtual"), but it gives back
> >>>>> only
> >>>>> 10% of method performance and in this case, code looks ugly (lambdas
> >>>>> can't
> >>>>> be used). Currently, I can't find any more ways to optimize the current
> >>>>> approach (except return to the switch/case block). Andrey Gura, as the
> >>>>> author of IGNITE-12568, maybe you have some ideas about optimization?
> >>>>>
> >>>>> Perhaps we should revert IGNITE-12568, but there are some metrics
> >>>>> already
> >>>>> created, which can't be rewritten using old message factory
> >>>>> implementation
> >>>>> (IGNITE-12756). Guys, WDYT?
> >>>>>
> >>>>
> >>>> Alexey,
> >>>>
> >>>> I see that IGNITE-12756 (metrics improvements) is already released in
> >>>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite
> >>>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics created for
> >>>> 2.9 that depend on the new message factory to unblock the release and deal
> >>>> with the optimizations in 2.10?
> >>>>
> >>>
>

[Alexey Plekhanov]

Hello guys,

I've tried to optimize tracing implementation (ticket [1]), it reduced the
drop, but not completely removed it.
Ivan Rakov, Alexander Lapin, can you please review the patch?
Ivan Artiukhov, can you please benchmark the patch [2] against 2.8.1
release on your environment?
With this patch on our environment, it's about a 3% drop left, it's close
to measurement error and I think such a drop is not a showstopper. Guys,
WDYT?

Also, I found that compatibility is broken for JDBC thin driver between 2.8
and 2.9 versions (ticket [3]). I think it's a blocker and should be
fixed in 2.9. I've prepared the patch.
Taras Ledkov, can you please review this patch?

And one more ticket I propose to include into 2.9 [4] (NIO message
send problem in some circumstances). I will cherry-pick it if there is no
objection.

[1] https://issues.apache.org/jira/browse/IGNITE-13411
[2] https://github.com/apache/ignite/pull/8223
[3] https://issues.apache.org/jira/browse/IGNITE-13414
[4] https://issues.apache.org/jira/browse/IGNITE-13361

пн, 7 сент. 2020 г. в 14:14, Maxim Muzafarov <[hidden email]>:

> Alexey,
>
> I propose to include [1] issue to the 2.9 release. Since this issue is
> related to the new master key change functionality which haven't been
> released yet I think it will be safe to cherry-pick commit to the
> release branch.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-13390
>
> On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov <[hidden email]> wrote:
> >
> > Hello, Igniters.
> >
> > Alexey, please, include one more Python thin client fix [1] into the 2.9
> release
> > It fixes kinda major issue - "Python client returns fields in wrong
> order since the 2 row when fields_count>10"
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12809
> > [2]
> https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
> >
> > > 31 авг. 2020 г., в 19:23, Alexey Goncharuk <[hidden email]>
> написал(а):
> > >
> > > Alexey, thanks, got it. I am not sure we can optimize anything out of
> the
> > > message factory with suppliers (at least I have no ideas right now), so
> > > most likely the only move here is to switch back to the switch approach
> > > somehow preserving the metrics part. Probably, inlining the Ignite
> messages
> > > to the IgniteMessageFactoryImpl should do the trick. Let me explore the
> > > code a bit.
> > >
> > > P.S. I am surprised by the impact this part makes for the performance.
> > > Message creation is indeed on the hot path, but a single virtual call
> > > should not make that much of a difference given the amount of other
> work
> > > happening during the message processing.
> > >
> > > пн, 31 авг. 2020 г. в 18:33, Alex Plehanov <[hidden email]>:
> > >
> > >> Alexey, sorry, I wrongly interpreted our benchmark results. Actually,
> we
> > >> were looking for a drop using bi-sect in the range between e6a7f93
> (first
> > >> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last
> commit in
> > >> the 2.9 branch). And we found these two problematic commits.
> > >>
> > >> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop between
> > >> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted
> IGNITE-13060
> > >> now and performance looks the same)
> > >>
> > >> Ticket IGNITE-12568 (MessageFactory refactoring) is not related to
> drop
> > >> between 2.8.1 and 2.9, but still has some performance problem, and we
> can
> > >> win back IGNITE-13060 drop by this ticket.
> > >>
> > >> Do we need more investigation on IGNITE-13060 or we leave it as is?
> > >>
> > >> What should we do with IGNITE-12568 (MessageFactory refactoring)?
> > >>
> > >> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk <
> [hidden email]
> > >>> :
> > >>
> > >>> Alexey,
> > >>>
> > >>> While investigating, I found that IGNITE-12568 has an incorrect fix
> > >>> version and is actually present in ignite-2.8.1 branch [1], so it
> cannot be
> > >>> the source of the drop against 2.8.1.
> > >>>
> > >>> P.S. Looks like we need to enforce a more accurate work with fix
> versions
> > >>> or develop some sort of tooling to verify the fix versions.
> > >>>
> > >>> --AG
> > >>>
> > >>> [1]
> > >>>
> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
> > >>>
> > >>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <
> [hidden email]
> > >>>> :
> > >>>
> > >>>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <[hidden email]
> >:
> > >>>>
> > >>>>> Guys,
> > >>>>>
> > >>>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568
> (reverted
> > >>>>> it
> > >>>>> locally) and got the same performance as on 2.8.1
> > >>>>>
> > >>>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace
> > >>>>> these
> > >>>>> hot paths, it's clear why we have performance drop here.
> > >>>>>
> > >>>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> > >>>>> refactored to an array of message suppliers. The message factory
> is on
> > >>>>> the
> > >>>>> hot path, which explains why this commit has an impact on total
> > >>>>> performance.
> > >>>>> I've checked JIT assembly output, done some JMH microbenchmarks,
> and
> > >>>>> found
> > >>>>> that old implementation of MessageFactory.create() about 30-35%
> faster
> > >>>>> than
> > >>>>> the new one. The reason - approach with switch/case can effectively
> > >>>>> inline
> > >>>>> message creation code, but with an array of suppliers relatively
> heavy
> > >>>>> "invokeinterface" cannot be skipped. I've tried to rewrite the code
> > >>>>> using
> > >>>>> an abstract class for suppliers instead of an interface (to
> > >>>>> replace "invokeinterface" with the "invokevirtual"), but it gives
> back
> > >>>>> only
> > >>>>> 10% of method performance and in this case, code looks ugly
> (lambdas
> > >>>>> can't
> > >>>>> be used). Currently, I can't find any more ways to optimize the
> current
> > >>>>> approach (except return to the switch/case block). Andrey Gura, as
> the
> > >>>>> author of IGNITE-12568, maybe you have some ideas about
> optimization?
> > >>>>>
> > >>>>> Perhaps we should revert IGNITE-12568, but there are some metrics
> > >>>>> already
> > >>>>> created, which can't be rewritten using old message factory
> > >>>>> implementation
> > >>>>> (IGNITE-12756). Guys, WDYT?
> > >>>>>
> > >>>>
> > >>>> Alexey,
> > >>>>
> > >>>> I see that IGNITE-12756 (metrics improvements) is already released
> in
> > >>>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only present
> in Ignite
> > >>>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics
> created for
> > >>>> 2.9 that depend on the new message factory to unblock the release
> and deal
> > >>>> with the optimizations in 2.10?
> > >>>>
> > >>>
> >
>

[Alexey Goncharuk]

Alexey,

I've tried to play with message factories locally, but unfortunately, I
cannot spot the difference between old and new implementation in
distributed benchmarks. I pushed an implementation of MessageFactoryImpl
with the old switch statement to the ignite-2.9-revert-12568 branch
(discussed this with Andrey Gura, the change should be compatible with the
new metrics as we still use the register() mechanics).

Can you check if this change makes any difference performance-wise in your
environment? If yes, we can go with runtime code generation in the long
term: register classes and generate a dynamic message factory with a switch
statement once all messages are registered (not in 2.9 though, obviously).

ср, 9 сент. 2020 г. в 14:53, Alex Plehanov <[hidden email]>:

> Hello guys,
>
> I've tried to optimize tracing implementation (ticket [1]), it reduced the
> drop, but not completely removed it.
> Ivan Rakov, Alexander Lapin, can you please review the patch?
> Ivan Artiukhov, can you please benchmark the patch [2] against 2.8.1
> release on your environment?
> With this patch on our environment, it's about a 3% drop left, it's close
> to measurement error and I think such a drop is not a showstopper. Guys,
> WDYT?
>
> Also, I found that compatibility is broken for JDBC thin driver between 2.8
> and 2.9 versions (ticket [3]). I think it's a blocker and should be
> fixed in 2.9. I've prepared the patch.
> Taras Ledkov, can you please review this patch?
>
> And one more ticket I propose to include into 2.9 [4] (NIO message
> send problem in some circumstances). I will cherry-pick it if there is no
> objection.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-13411
> [2] https://github.com/apache/ignite/pull/8223
> [3] https://issues.apache.org/jira/browse/IGNITE-13414
> [4] https://issues.apache.org/jira/browse/IGNITE-13361
>
> пн, 7 сент. 2020 г. в 14:14, Maxim Muzafarov <[hidden email]>:
>
> > Alexey,
> >
> > I propose to include [1] issue to the 2.9 release. Since this issue is
> > related to the new master key change functionality which haven't been
> > released yet I think it will be safe to cherry-pick commit to the
> > release branch.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-13390
> >
> > On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov <[hidden email]>
> wrote:
> > >
> > > Hello, Igniters.
> > >
> > > Alexey, please, include one more Python thin client fix [1] into the
> 2.9
> > release
> > > It fixes kinda major issue - "Python client returns fields in wrong
> > order since the 2 row when fields_count>10"
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12809
> > > [2]
> >
> https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
> > >
> > > > 31 авг. 2020 г., в 19:23, Alexey Goncharuk <
> [hidden email]>
> > написал(а):
> > > >
> > > > Alexey, thanks, got it. I am not sure we can optimize anything out of
> > the
> > > > message factory with suppliers (at least I have no ideas right now),
> so
> > > > most likely the only move here is to switch back to the switch
> approach
> > > > somehow preserving the metrics part. Probably, inlining the Ignite
> > messages
> > > > to the IgniteMessageFactoryImpl should do the trick. Let me explore
> the
> > > > code a bit.
> > > >
> > > > P.S. I am surprised by the impact this part makes for the
> performance.
> > > > Message creation is indeed on the hot path, but a single virtual call
> > > > should not make that much of a difference given the amount of other
> > work
> > > > happening during the message processing.
> > > >
> > > > пн, 31 авг. 2020 г. в 18:33, Alex Plehanov <[hidden email]
> >:
> > > >
> > > >> Alexey, sorry, I wrongly interpreted our benchmark results.
> Actually,
> > we
> > > >> were looking for a drop using bi-sect in the range between e6a7f93
> > (first
> > > >> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last
> > commit in
> > > >> the 2.9 branch). And we found these two problematic commits.
> > > >>
> > > >> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop
> between
> > > >> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted
> > IGNITE-13060
> > > >> now and performance looks the same)
> > > >>
> > > >> Ticket IGNITE-12568 (MessageFactory refactoring) is not related to
> > drop
> > > >> between 2.8.1 and 2.9, but still has some performance problem, and
> we
> > can
> > > >> win back IGNITE-13060 drop by this ticket.
> > > >>
> > > >> Do we need more investigation on IGNITE-13060 or we leave it as is?
> > > >>
> > > >> What should we do with IGNITE-12568 (MessageFactory refactoring)?
> > > >>
> > > >> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk <
> > [hidden email]
> > > >>> :
> > > >>
> > > >>> Alexey,
> > > >>>
> > > >>> While investigating, I found that IGNITE-12568 has an incorrect fix
> > > >>> version and is actually present in ignite-2.8.1 branch [1], so it
> > cannot be
> > > >>> the source of the drop against 2.8.1.
> > > >>>
> > > >>> P.S. Looks like we need to enforce a more accurate work with fix
> > versions
> > > >>> or develop some sort of tooling to verify the fix versions.
> > > >>>
> > > >>> --AG
> > > >>>
> > > >>> [1]
> > > >>>
> >
> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
> > > >>>
> > > >>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <
> > [hidden email]
> > > >>>> :
> > > >>>
> > > >>>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <
> [hidden email]
> > >:
> > > >>>>
> > > >>>>> Guys,
> > > >>>>>
> > > >>>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568
> > (reverted
> > > >>>>> it
> > > >>>>> locally) and got the same performance as on 2.8.1
> > > >>>>>
> > > >>>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to
> trace
> > > >>>>> these
> > > >>>>> hot paths, it's clear why we have performance drop here.
> > > >>>>>
> > > >>>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block was
> > > >>>>> refactored to an array of message suppliers. The message factory
> > is on
> > > >>>>> the
> > > >>>>> hot path, which explains why this commit has an impact on total
> > > >>>>> performance.
> > > >>>>> I've checked JIT assembly output, done some JMH microbenchmarks,
> > and
> > > >>>>> found
> > > >>>>> that old implementation of MessageFactory.create() about 30-35%
> > faster
> > > >>>>> than
> > > >>>>> the new one. The reason - approach with switch/case can
> effectively
> > > >>>>> inline
> > > >>>>> message creation code, but with an array of suppliers relatively
> > heavy
> > > >>>>> "invokeinterface" cannot be skipped. I've tried to rewrite the
> code
> > > >>>>> using
> > > >>>>> an abstract class for suppliers instead of an interface (to
> > > >>>>> replace "invokeinterface" with the "invokevirtual"), but it gives
> > back
> > > >>>>> only
> > > >>>>> 10% of method performance and in this case, code looks ugly
> > (lambdas
> > > >>>>> can't
> > > >>>>> be used). Currently, I can't find any more ways to optimize the
> > current
> > > >>>>> approach (except return to the switch/case block). Andrey Gura,
> as
> > the
> > > >>>>> author of IGNITE-12568, maybe you have some ideas about
> > optimization?
> > > >>>>>
> > > >>>>> Perhaps we should revert IGNITE-12568, but there are some metrics
> > > >>>>> already
> > > >>>>> created, which can't be rewritten using old message factory
> > > >>>>> implementation
> > > >>>>> (IGNITE-12756). Guys, WDYT?
> > > >>>>>
> > > >>>>
> > > >>>> Alexey,
> > > >>>>
> > > >>>> I see that IGNITE-12756 (metrics improvements) is already released
> > in
> > > >>>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only present
> > in Ignite
> > > >>>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics
> > created for
> > > >>>> 2.9 that depend on the new message factory to unblock the release
> > and deal
> > > >>>> with the optimizations in 2.10?
> > > >>>>
> > > >>>
> > >
> >
>

[Artem Budnikov]

Hi Everyone,

I posted an instruction on how to publish the docs on ignite.apache.org/docs
[1]. When you finish with Ignite 2.9, you can update the docs by following
the instruction. Unfortunately, I won't be able to spend any time on this
project any longer. You can send your pull requests and questions about the
documentation to Denis Magda.

-Artem

[1] : https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

On Thu, Sep 10, 2020 at 2:45 PM Alexey Goncharuk <[hidden email]>
wrote:

> Alexey,
>
> I've tried to play with message factories locally, but unfortunately, I
> cannot spot the difference between old and new implementation in
> distributed benchmarks. I pushed an implementation of MessageFactoryImpl
> with the old switch statement to the ignite-2.9-revert-12568 branch
> (discussed this with Andrey Gura, the change should be compatible with the
> new metrics as we still use the register() mechanics).
>
> Can you check if this change makes any difference performance-wise in your
> environment? If yes, we can go with runtime code generation in the long
> term: register classes and generate a dynamic message factory with a switch
> statement once all messages are registered (not in 2.9 though, obviously).
>
> ср, 9 сент. 2020 г. в 14:53, Alex Plehanov <[hidden email]>:
>
> > Hello guys,
> >
> > I've tried to optimize tracing implementation (ticket [1]), it reduced
> the
> > drop, but not completely removed it.
> > Ivan Rakov, Alexander Lapin, can you please review the patch?
> > Ivan Artiukhov, can you please benchmark the patch [2] against 2.8.1
> > release on your environment?
> > With this patch on our environment, it's about a 3% drop left, it's close
> > to measurement error and I think such a drop is not a showstopper. Guys,
> > WDYT?
> >
> > Also, I found that compatibility is broken for JDBC thin driver between
> 2.8
> > and 2.9 versions (ticket [3]). I think it's a blocker and should be
> > fixed in 2.9. I've prepared the patch.
> > Taras Ledkov, can you please review this patch?
> >
> > And one more ticket I propose to include into 2.9 [4] (NIO message
> > send problem in some circumstances). I will cherry-pick it if there is no
> > objection.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-13411
> > [2] https://github.com/apache/ignite/pull/8223
> > [3] https://issues.apache.org/jira/browse/IGNITE-13414
> > [4] https://issues.apache.org/jira/browse/IGNITE-13361
> >
> > пн, 7 сент. 2020 г. в 14:14, Maxim Muzafarov <[hidden email]>:
> >
> > > Alexey,
> > >
> > > I propose to include [1] issue to the 2.9 release. Since this issue is
> > > related to the new master key change functionality which haven't been
> > > released yet I think it will be safe to cherry-pick commit to the
> > > release branch.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-13390
> > >
> > > On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov <[hidden email]>
> > wrote:
> > > >
> > > > Hello, Igniters.
> > > >
> > > > Alexey, please, include one more Python thin client fix [1] into the
> > 2.9
> > > release
> > > > It fixes kinda major issue - "Python client returns fields in wrong
> > > order since the 2 row when fields_count>10"
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-12809
> > > > [2]
> > >
> >
> https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
> > > >
> > > > > 31 авг. 2020 г., в 19:23, Alexey Goncharuk <
> > [hidden email]>
> > > написал(а):
> > > > >
> > > > > Alexey, thanks, got it. I am not sure we can optimize anything out
> of
> > > the
> > > > > message factory with suppliers (at least I have no ideas right
> now),
> > so
> > > > > most likely the only move here is to switch back to the switch
> > approach
> > > > > somehow preserving the metrics part. Probably, inlining the Ignite
> > > messages
> > > > > to the IgniteMessageFactoryImpl should do the trick. Let me explore
> > the
> > > > > code a bit.
> > > > >
> > > > > P.S. I am surprised by the impact this part makes for the
> > performance.
> > > > > Message creation is indeed on the hot path, but a single virtual
> call
> > > > > should not make that much of a difference given the amount of other
> > > work
> > > > > happening during the message processing.
> > > > >
> > > > > пн, 31 авг. 2020 г. в 18:33, Alex Plehanov <
> [hidden email]
> > >:
> > > > >
> > > > >> Alexey, sorry, I wrongly interpreted our benchmark results.
> > Actually,
> > > we
> > > > >> were looking for a drop using bi-sect in the range between e6a7f93
> > > (first
> > > > >> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last
> > > commit in
> > > > >> the 2.9 branch). And we found these two problematic commits.
> > > > >>
> > > > >> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop
> > between
> > > > >> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted
> > > IGNITE-13060
> > > > >> now and performance looks the same)
> > > > >>
> > > > >> Ticket IGNITE-12568 (MessageFactory refactoring) is not related to
> > > drop
> > > > >> between 2.8.1 and 2.9, but still has some performance problem, and
> > we
> > > can
> > > > >> win back IGNITE-13060 drop by this ticket.
> > > > >>
> > > > >> Do we need more investigation on IGNITE-13060 or we leave it as
> is?
> > > > >>
> > > > >> What should we do with IGNITE-12568 (MessageFactory refactoring)?
> > > > >>
> > > > >> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk <
> > > [hidden email]
> > > > >>> :
> > > > >>
> > > > >>> Alexey,
> > > > >>>
> > > > >>> While investigating, I found that IGNITE-12568 has an incorrect
> fix
> > > > >>> version and is actually present in ignite-2.8.1 branch [1], so it
> > > cannot be
> > > > >>> the source of the drop against 2.8.1.
> > > > >>>
> > > > >>> P.S. Looks like we need to enforce a more accurate work with fix
> > > versions
> > > > >>> or develop some sort of tooling to verify the fix versions.
> > > > >>>
> > > > >>> --AG
> > > > >>>
> > > > >>> [1]
> > > > >>>
> > >
> >
> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
> > > > >>>
> > > > >>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <
> > > [hidden email]
> > > > >>>> :
> > > > >>>
> > > > >>>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <
> > [hidden email]
> > > >:
> > > > >>>>
> > > > >>>>> Guys,
> > > > >>>>>
> > > > >>>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568
> > > (reverted
> > > > >>>>> it
> > > > >>>>> locally) and got the same performance as on 2.8.1
> > > > >>>>>
> > > > >>>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to
> > trace
> > > > >>>>> these
> > > > >>>>> hot paths, it's clear why we have performance drop here.
> > > > >>>>>
> > > > >>>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block
> was
> > > > >>>>> refactored to an array of message suppliers. The message
> factory
> > > is on
> > > > >>>>> the
> > > > >>>>> hot path, which explains why this commit has an impact on total
> > > > >>>>> performance.
> > > > >>>>> I've checked JIT assembly output, done some JMH
> microbenchmarks,
> > > and
> > > > >>>>> found
> > > > >>>>> that old implementation of MessageFactory.create() about 30-35%
> > > faster
> > > > >>>>> than
> > > > >>>>> the new one. The reason - approach with switch/case can
> > effectively
> > > > >>>>> inline
> > > > >>>>> message creation code, but with an array of suppliers
> relatively
> > > heavy
> > > > >>>>> "invokeinterface" cannot be skipped. I've tried to rewrite the
> > code
> > > > >>>>> using
> > > > >>>>> an abstract class for suppliers instead of an interface (to
> > > > >>>>> replace "invokeinterface" with the "invokevirtual"), but it
> gives
> > > back
> > > > >>>>> only
> > > > >>>>> 10% of method performance and in this case, code looks ugly
> > > (lambdas
> > > > >>>>> can't
> > > > >>>>> be used). Currently, I can't find any more ways to optimize the
> > > current
> > > > >>>>> approach (except return to the switch/case block). Andrey Gura,
> > as
> > > the
> > > > >>>>> author of IGNITE-12568, maybe you have some ideas about
> > > optimization?
> > > > >>>>>
> > > > >>>>> Perhaps we should revert IGNITE-12568, but there are some
> metrics
> > > > >>>>> already
> > > > >>>>> created, which can't be rewritten using old message factory
> > > > >>>>> implementation
> > > > >>>>> (IGNITE-12756). Guys, WDYT?
> > > > >>>>>
> > > > >>>>
> > > > >>>> Alexey,
> > > > >>>>
> > > > >>>> I see that IGNITE-12756 (metrics improvements) is already
> released
> > > in
> > > > >>>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only
> present
> > > in Ignite
> > > > >>>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics
> > > created for
> > > > >>>> 2.9 that depend on the new message factory to unblock the
> release
> > > and deal
> > > > >>>> with the optimizations in 2.10?
> > > > >>>>
> > > > >>>
> > > >
> > >
> >
>

[Alexey Plekhanov]

Alexey,

We've benchmarked by yardstick commits 130376741bf vs ed52559eb95 and the
performance of ed52559eb95 is better for about 2.5% on average on our
environment (about the same results we got benchmarking 65c30ec6 vs
0606f03d). We've made 24 runs for each commit of
IgnitePutTxImplicitBenchmark (we got maximum drop for 2.9 on this
benchmark), 200 seconds warmup, 300 seconds benchmark, 6 servers, 5 clients
50 threads each. Yardstick results for this configuration:
Commit 130376741bf: avg TPS=164096, avg latency=9173464 ns
Commit ed52559eb95: avg TPS=168283, avg latency=8945908 ns

пт, 11 сент. 2020 г. в 09:51, Artem Budnikov <[hidden email]>:

> Hi Everyone,
>
> I posted an instruction on how to publish the docs on
> ignite.apache.org/docs [1]. When you finish with Ignite 2.9, you can
> update the docs by following the instruction. Unfortunately, I won't be
> able to spend any time on this project any longer. You can send your pull
> requests and questions about the documentation to Denis Magda.
>
> -Artem
>
> [1] : https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
>
> On Thu, Sep 10, 2020 at 2:45 PM Alexey Goncharuk <
> [hidden email]> wrote:
>
>> Alexey,
>>
>> I've tried to play with message factories locally, but unfortunately, I
>> cannot spot the difference between old and new implementation in
>> distributed benchmarks. I pushed an implementation of MessageFactoryImpl
>> with the old switch statement to the ignite-2.9-revert-12568 branch
>> (discussed this with Andrey Gura, the change should be compatible with the
>> new metrics as we still use the register() mechanics).
>>
>> Can you check if this change makes any difference performance-wise in your
>> environment? If yes, we can go with runtime code generation in the long
>> term: register classes and generate a dynamic message factory with a
>> switch
>> statement once all messages are registered (not in 2.9 though, obviously).
>>
>> ср, 9 сент. 2020 г. в 14:53, Alex Plehanov <[hidden email]>:
>>
>> > Hello guys,
>> >
>> > I've tried to optimize tracing implementation (ticket [1]), it reduced
>> the
>> > drop, but not completely removed it.
>> > Ivan Rakov, Alexander Lapin, can you please review the patch?
>> > Ivan Artiukhov, can you please benchmark the patch [2] against 2.8.1
>> > release on your environment?
>> > With this patch on our environment, it's about a 3% drop left, it's
>> close
>> > to measurement error and I think such a drop is not a showstopper. Guys,
>> > WDYT?
>> >
>> > Also, I found that compatibility is broken for JDBC thin driver between
>> 2.8
>> > and 2.9 versions (ticket [3]). I think it's a blocker and should be
>> > fixed in 2.9. I've prepared the patch.
>> > Taras Ledkov, can you please review this patch?
>> >
>> > And one more ticket I propose to include into 2.9 [4] (NIO message
>> > send problem in some circumstances). I will cherry-pick it if there is
>> no
>> > objection.
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-13411
>> > [2] https://github.com/apache/ignite/pull/8223
>> > [3] https://issues.apache.org/jira/browse/IGNITE-13414
>> > [4] https://issues.apache.org/jira/browse/IGNITE-13361
>> >
>> > пн, 7 сент. 2020 г. в 14:14, Maxim Muzafarov <[hidden email]>:
>> >
>> > > Alexey,
>> > >
>> > > I propose to include [1] issue to the 2.9 release. Since this issue is
>> > > related to the new master key change functionality which haven't been
>> > > released yet I think it will be safe to cherry-pick commit to the
>> > > release branch.
>> > >
>> > > [1] https://issues.apache.org/jira/browse/IGNITE-13390
>> > >
>> > > On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov <[hidden email]>
>> > wrote:
>> > > >
>> > > > Hello, Igniters.
>> > > >
>> > > > Alexey, please, include one more Python thin client fix [1] into the
>> > 2.9
>> > > release
>> > > > It fixes kinda major issue - "Python client returns fields in wrong
>> > > order since the 2 row when fields_count>10"
>> > > >
>> > > > [1] https://issues.apache.org/jira/browse/IGNITE-12809
>> > > > [2]
>> > >
>> >
>> https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
>> > > >
>> > > > > 31 авг. 2020 г., в 19:23, Alexey Goncharuk <
>> > [hidden email]>
>> > > написал(а):
>> > > > >
>> > > > > Alexey, thanks, got it. I am not sure we can optimize anything
>> out of
>> > > the
>> > > > > message factory with suppliers (at least I have no ideas right
>> now),
>> > so
>> > > > > most likely the only move here is to switch back to the switch
>> > approach
>> > > > > somehow preserving the metrics part. Probably, inlining the Ignite
>> > > messages
>> > > > > to the IgniteMessageFactoryImpl should do the trick. Let me
>> explore
>> > the
>> > > > > code a bit.
>> > > > >
>> > > > > P.S. I am surprised by the impact this part makes for the
>> > performance.
>> > > > > Message creation is indeed on the hot path, but a single virtual
>> call
>> > > > > should not make that much of a difference given the amount of
>> other
>> > > work
>> > > > > happening during the message processing.
>> > > > >
>> > > > > пн, 31 авг. 2020 г. в 18:33, Alex Plehanov <
>> [hidden email]
>> > >:
>> > > > >
>> > > > >> Alexey, sorry, I wrongly interpreted our benchmark results.
>> > Actually,
>> > > we
>> > > > >> were looking for a drop using bi-sect in the range between
>> e6a7f93
>> > > (first
>> > > > >> commit in the 2.9 branch after 2.8 branch cut) and 6592dfa5 (last
>> > > commit in
>> > > > >> the 2.9 branch). And we found these two problematic commits.
>> > > > >>
>> > > > >> Perhaps only IGNITE-13060 (Tracing) is responsible for a drop
>> > between
>> > > > >> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 with reverted
>> > > IGNITE-13060
>> > > > >> now and performance looks the same)
>> > > > >>
>> > > > >> Ticket IGNITE-12568 (MessageFactory refactoring) is not related
>> to
>> > > drop
>> > > > >> between 2.8.1 and 2.9, but still has some performance problem,
>> and
>> > we
>> > > can
>> > > > >> win back IGNITE-13060 drop by this ticket.
>> > > > >>
>> > > > >> Do we need more investigation on IGNITE-13060 or we leave it as
>> is?
>> > > > >>
>> > > > >> What should we do with IGNITE-12568 (MessageFactory refactoring)?
>> > > > >>
>> > > > >> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk <
>> > > [hidden email]
>> > > > >>> :
>> > > > >>
>> > > > >>> Alexey,
>> > > > >>>
>> > > > >>> While investigating, I found that IGNITE-12568 has an incorrect
>> fix
>> > > > >>> version and is actually present in ignite-2.8.1 branch [1], so
>> it
>> > > cannot be
>> > > > >>> the source of the drop against 2.8.1.
>> > > > >>>
>> > > > >>> P.S. Looks like we need to enforce a more accurate work with fix
>> > > versions
>> > > > >>> or develop some sort of tooling to verify the fix versions.
>> > > > >>>
>> > > > >>> --AG
>> > > > >>>
>> > > > >>> [1]
>> > > > >>>
>> > >
>> >
>> https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
>> > > > >>>
>> > > > >>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk <
>> > > [hidden email]
>> > > > >>>> :
>> > > > >>>
>> > > > >>>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <
>> > [hidden email]
>> > > >:
>> > > > >>>>
>> > > > >>>>> Guys,
>> > > > >>>>>
>> > > > >>>>> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568
>> > > (reverted
>> > > > >>>>> it
>> > > > >>>>> locally) and got the same performance as on 2.8.1
>> > > > >>>>>
>> > > > >>>>> IGNITE-13060 (Tracing) - some code was added to hot paths, to
>> > trace
>> > > > >>>>> these
>> > > > >>>>> hot paths, it's clear why we have performance drop here.
>> > > > >>>>>
>> > > > >>>>> IGNITE-12568 (MessageFactory refactoring) - switch/case block
>> was
>> > > > >>>>> refactored to an array of message suppliers. The message
>> factory
>> > > is on
>> > > > >>>>> the
>> > > > >>>>> hot path, which explains why this commit has an impact on
>> total
>> > > > >>>>> performance.
>> > > > >>>>> I've checked JIT assembly output, done some JMH
>> microbenchmarks,
>> > > and
>> > > > >>>>> found
>> > > > >>>>> that old implementation of MessageFactory.create() about
>> 30-35%
>> > > faster
>> > > > >>>>> than
>> > > > >>>>> the new one. The reason - approach with switch/case can
>> > effectively
>> > > > >>>>> inline
>> > > > >>>>> message creation code, but with an array of suppliers
>> relatively
>> > > heavy
>> > > > >>>>> "invokeinterface" cannot be skipped. I've tried to rewrite the
>> > code
>> > > > >>>>> using
>> > > > >>>>> an abstract class for suppliers instead of an interface (to
>> > > > >>>>> replace "invokeinterface" with the "invokevirtual"), but it
>> gives
>> > > back
>> > > > >>>>> only
>> > > > >>>>> 10% of method performance and in this case, code looks ugly
>> > > (lambdas
>> > > > >>>>> can't
>> > > > >>>>> be used). Currently, I can't find any more ways to optimize
>> the
>> > > current
>> > > > >>>>> approach (except return to the switch/case block). Andrey
>> Gura,
>> > as
>> > > the
>> > > > >>>>> author of IGNITE-12568, maybe you have some ideas about
>> > > optimization?
>> > > > >>>>>
>> > > > >>>>> Perhaps we should revert IGNITE-12568, but there are some
>> metrics
>> > > > >>>>> already
>> > > > >>>>> created, which can't be rewritten using old message factory
>> > > > >>>>> implementation
>> > > > >>>>> (IGNITE-12756). Guys, WDYT?
>> > > > >>>>>
>> > > > >>>>
>> > > > >>>> Alexey,
>> > > > >>>>
>> > > > >>>> I see that IGNITE-12756 (metrics improvements) is already
>> released
>> > > in
>> > > > >>>> Ignite 2.8.1 while IGNITE-12568 (message factory) is only
>> present
>> > > in Ignite
>> > > > >>>> 2.9. Let's revert both IGNITE-12568 and whichever new metrics
>> > > created for
>> > > > >>>> 2.9 that depend on the new message factory to unblock the
>> release
>> > > and deal
>> > > > >>>> with the optimizations in 2.10?
>> > > > >>>>
>> > > > >>>
>> > > >
>> > >
>> >
>>
>