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