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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
