[JCS] JCache CDI integration

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[JCS] JCache CDI integration

Romain Manni-Bucau
Hi guys,

Due to some performance issues due to the reflection usage in the JCache
CDI integration we have, I pushed some changes in that layer.

It is not expected to change anything functionally but since the changes
were quite more deep than I expected don't hesitate to shout if you observe
some surprising behavior.

Romain
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] JCache CDI integration

garydgregory
Do you plan on making a release for push this out?

Gary

On Fri, Sep 1, 2017 at 9:21 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> Hi guys,
>
> Due to some performance issues due to the reflection usage in the JCache
> CDI integration we have, I pushed some changes in that layer.
>
> It is not expected to change anything functionally but since the changes
> were quite more deep than I expected don't hesitate to shout if you observe
> some surprising behavior.
>
> Romain
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] JCache CDI integration

Romain Manni-Bucau
I'm waiting for some confirmation on a complex app but it can likely be the
case in ~1 month if nobody does it before.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-01 17:26 GMT+02:00 Gary Gregory <[hidden email]>:

> Do you plan on making a release for push this out?
>
> Gary
>
> On Fri, Sep 1, 2017 at 9:21 AM, Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > Hi guys,
> >
> > Due to some performance issues due to the reflection usage in the JCache
> > CDI integration we have, I pushed some changes in that layer.
> >
> > It is not expected to change anything functionally but since the changes
> > were quite more deep than I expected don't hesitate to shout if you
> observe
> > some surprising behavior.
> >
> > Romain
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] JCache CDI integration

garydgregory
Well, you know me, I like RERO! :-)

G

On Fri, Sep 1, 2017 at 9:32 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> I'm waiting for some confirmation on a complex app but it can likely be the
> case in ~1 month if nobody does it before.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-09-01 17:26 GMT+02:00 Gary Gregory <[hidden email]>:
>
> > Do you plan on making a release for push this out?
> >
> > Gary
> >
> > On Fri, Sep 1, 2017 at 9:21 AM, Romain Manni-Bucau <
> [hidden email]>
> > wrote:
> >
> > > Hi guys,
> > >
> > > Due to some performance issues due to the reflection usage in the
> JCache
> > > CDI integration we have, I pushed some changes in that layer.
> > >
> > > It is not expected to change anything functionally but since the
> changes
> > > were quite more deep than I expected don't hesitate to shout if you
> > observe
> > > some surprising behavior.
> > >
> > > Romain
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] JCache CDI integration

Romain Manni-Bucau
Ok, got the confirmation for the reflection fix.

Now we lock in CompositeCache.get. Wonder if we could have a lock free
MemoryCache implementation, at least for read side of things. Sounds doable
using ConcurrentMap like algorithms but can require more time than I have
ATM to validate it :(. In other words: perf issue we can hit now is we
don't scale in reads with thread number since we are synchronized with all
the MemoryCache we provide OOTB.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-01 18:47 GMT+02:00 Gary Gregory <[hidden email]>:

> Well, you know me, I like RERO! :-)
>
> G
>
> On Fri, Sep 1, 2017 at 9:32 AM, Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > I'm waiting for some confirmation on a complex app but it can likely be
> the
> > case in ~1 month if nobody does it before.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-09-01 17:26 GMT+02:00 Gary Gregory <[hidden email]>:
> >
> > > Do you plan on making a release for push this out?
> > >
> > > Gary
> > >
> > > On Fri, Sep 1, 2017 at 9:21 AM, Romain Manni-Bucau <
> > [hidden email]>
> > > wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Due to some performance issues due to the reflection usage in the
> > JCache
> > > > CDI integration we have, I pushed some changes in that layer.
> > > >
> > > > It is not expected to change anything functionally but since the
> > changes
> > > > were quite more deep than I expected don't hesitate to shout if you
> > > observe
> > > > some surprising behavior.
> > > >
> > > > Romain
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [JCS] JCache CDI integration

Thomas Vandahl
On 02.09.17 10:41, Romain Manni-Bucau wrote:
> Ok, got the confirmation for the reflection fix.
>
> Now we lock in CompositeCache.get. Wonder if we could have a lock free
> MemoryCache implementation, at least for read side of things. Sounds doable
> using ConcurrentMap like algorithms but can require more time than I have
> ATM to validate it :(. In other words: perf issue we can hit now is we
> don't scale in reads with thread number since we are synchronized with all
> the MemoryCache we provide OOTB.

I did several experiments with different locking mechanisms and found no
real improvement over the solution as it is now. You actually need to
lock on the key to make sure any write operation on that particular key
has finished before the result is returned. IOW, the overhead effort you
need to put into the management of this type of key locking is bigger
than the impact of the synchronization. At least that is what I found out.

Bye, Thomas.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [JCS] JCache CDI integration

Romain Manni-Bucau
Almost had the same except when using a lot of keys where a single lock is
an issue or a plain map which is still 4 times faster under a medium load
just doing gets (50 threads). Issue is we ignore if the underlying memcache
is thread safe which means we could avoid the composite cache
synchronization when there is no aux cache and be close to a plain map, no?



Le 3 sept. 2017 19:53, "Thomas Vandahl" <[hidden email]> a écrit :

> On 02.09.17 10:41, Romain Manni-Bucau wrote:
> > Ok, got the confirmation for the reflection fix.
> >
> > Now we lock in CompositeCache.get. Wonder if we could have a lock free
> > MemoryCache implementation, at least for read side of things. Sounds
> doable
> > using ConcurrentMap like algorithms but can require more time than I have
> > ATM to validate it :(. In other words: perf issue we can hit now is we
> > don't scale in reads with thread number since we are synchronized with
> all
> > the MemoryCache we provide OOTB.
>
> I did several experiments with different locking mechanisms and found no
> real improvement over the solution as it is now. You actually need to
> lock on the key to make sure any write operation on that particular key
> has finished before the result is returned. IOW, the overhead effort you
> need to put into the management of this type of key locking is bigger
> than the impact of the synchronization. At least that is what I found out.
>
> Bye, Thomas.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>