Hi Sanne,
(redirected back to infinispan-dev)
Hello,
I've run the same Infinispan benchmark mentioned today on the
Infinispan mailing list, but having the goal to test NAKACK2
development.
Infinispan 5.1.0 at 2d7c65e with JGroups 3.0.2.Final :
Done 844,952,883 transactional operations in 22.08 minutes using 5.1.0-SNAPSHOT
839,810,425 reads and 5,142,458 writes
Reads / second: 634,028
Writes/ second: 3,882
Same Infinispan, with JGroups b294965 (and reconfigured for NAKACK2):
Done 807,220,989 transactional operations in 18.15 minutes using 5.1.0-SNAPSHOT
804,162,247 reads and 3,058,742 writes
Reads / second: 738,454
Writes/ second: 2,808
same versions and configuration, run it again as I was too surprised:
Done 490,928,700 transactional operations in 10.94 minutes using 5.1.0-SNAPSHOT
489,488,339 reads and 1,440,361 writes
Reads / second: 745,521
Writes/ second: 2,193
So the figures aren't very stable, I might need to run longer tests,
but there seems to be a trend of this new protocol speeding up Read
operations at the cost of writes.
This is really strange !
In my own tests with 2 members on the same box (using MPerf), I found
that the blockings on Table.add() and Table.removeMany() were much
smaller than in the previous tests, and now the
TP.TransferQueueBundler.send() method was the culprit #1 by far ! Of
course, still being much smaller than the previous highest blockings !
I'll run Transactional on my own box today, to see the diffs between
various versions of JGroups.
Can you send me your bench.sh ? If I don't change the values, the test
takes forever !
--
Bela Ban
Lead JGroups (
http://www.jgroups.org)
JBoss / Red Hat