[infinispan-dev] benchmarking 5.1 vs 5.0

Galder Zamarreño galder at redhat.com
Wed Dec 14 08:51:42 EST 2011


See below for further comments...

On Dec 14, 2011, at 2:30 PM, Galder Zamarreño wrote:

> Hi Slorg,
> 
> Once again, apologies for the delay getting back to you. Find comments below:
> 
> On Nov 29, 2011, at 6:34 PM, Slorg1 wrote:
> 
>> </snip>
> 
>> 2. Then I realized that the BaseRegion class also had some logic that
>> I was running into that was suspending transactions. I changed the
>> methods "suspend" and "resume(Transaction tx)" to do nothing (suspends
>> returns systematically null and resume expect always null as an input
>> with my changes).
>> 
>> This change was what brought me to realize that there was a MAJOR
>> issue with hibernate (at least in 3.5.5) when doing that.
>> 
>> The timestamp cache/region has a special behaviour in "ActionQueue".
>> If you look at "AfterTransactionCompletionProcessQueue" the method
>> "public void afterTransactionCompletion(boolean success)" once all is
>> done, checks if there is a cache and pushes a set of invalidations.
>> The main issue here is that:
>> 1. my transaction was already successfully committed by hibernate and
>> these operations are done outside of the scope of the transaction.
>> 2. consequence of #1: I had set autoCommit to false, so no
>> transactions were auto started for me, so the invalidations failed
>> systematically (I think it was correct for the invalidations to fail).
>> 
>> (The changes to "fix" that are enclosed to the email, they are simple).
> 
> A patch would be easier to consume with the exact changes you made, as opposed to having to compare with the source files.
> 
> I'm checking out Hibernate 3.5.5 to see what changes you made exactly…

Btw, seems like you've changed tabbing as well, so a lot of lines are considered different using simple diff.

At first glance, I'm not sure you can apply the changes you suggest to ActionQueue. Someone from the Hibernate team that knows that code better (i.e. Steve, Emmanuel or Sanne) could verify them. I'd suggest you open a forum thread in the Hibernate dev list to discuss this particular change.

You have to remember that this code applies to all cache providers, not only Infiinispan and hence it covers other non-transactional cache providers.

I'm also failing to understand why the invalidations failed even if they run outside of the transaction. It would have already worked this way pre-5.1. So, please provide more info on these failures.

> 
> Btw, have you tried your changes with latest Hibernate 4.0 CR release and 5.1.0.CR1?
> 
>> 
>> Thus, this leads me to say that a pure transactional cache with
>> autoCommit set to false cannot work at this point without the changes
>> I made to my own. I correctly works for me and after other changes I
>> got it to perform really well.
>> 
>> On that note, since we are talking performance, I explored the
>> batching functionality of infinispan (which is great!!). It does not
>> quite perform as is for all regions/cache. Indeed, if you run into the
>> issue I describe above in the timestamp cache/region, and your
>> autoCommit is set to true, no batching happens (you are indeed outside
>> of the transaction which started the batch) and the
>> invalidation/replication is super expensive: 2 commands/messages per
>> invalidation (one for prepare and one for commit). Implementing the
>> changes I described allowed the batching to work for my timestamp
>> region and that is when I got an additional 2x factor and everything
>> is lightening fast. When I say 2x factor, I mean a total of 10x faster
>> with all the changes I put in versus, the 5.1.0 BETA5 out of the box
>> (from 1 sec to 100ms per http transaction on my API !!). This is for
>> asynchronous invalidation, it is slower with synchronous.

So, what exactly did you change batching wise? Config? Or just start/stop a batch somewhere?

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list