[infinispan-dev] New bundler performance

Bela Ban bban at redhat.com
Wed Jun 12 09:16:58 EDT 2013



On 06/12/2013 04:54 AM, Radim Vansa wrote:
> Hi,
>
> I was going through the commits (running tests on each of them) to
> seek the performance regression we've recently discovered and it
> seems that our test (replicated udp non-transactional stress test on
> 4 nodes) experiences a serious regression on the commit
>
> ISPN-2848 Use the new bundling mechanism from JGroups 3.3.0
> (73da108cdcf9db4f3edbcd6dbda6938d6e45d148)
>
> The performance drops from about 7800 writes/s to 4800 writes/s, and
> from 1.5M reads/s to 1.2M reads/s (having slower reads in replicated
> mode is really odd).


Is this using sync or async replication ?

You could set UDP.bundler_type="old" to see if the old bundler makes a 
difference.

Yes, reads should have *nothing* to do with the bundler as there should 
not be any communication on reads !

Maybe you should instrument the reads with byteman and see if they cause 
any communication.


> It seems that the bundler is not really as good as we hoped for - it
> may be the bottleneck. I have tried to create another bundler which
> shares the queue between 4 instances of TransportQueueBundler (so, 4
> threads are actually sending the messages which go into one queue)
> and the performance mildly improved - to 5200 writes/s, but that's
> not enough.

I'm currently at the summit, but do you have a test that I could run 
when I'm back to reproduce the performance issue ?


>
> Radim
>
> Note: you may have seen my conversation with Pedro Ruivo on IRC about
> the bundler several days ago, in that time our configuration had old
> bundler. This was fixed, but as I have not built Infinispan properly
> (something got cached), I have not noticed the regression between
> these builds.

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss


More information about the infinispan-dev mailing list