[infinispan-dev] New bundler performance

[Radim Vansa]

Hi Pedro

----- Original Message -----
| From: "Pedro Ruivo" <pedro at infinispan.org>
| To: infinispan-dev at lists.jboss.org
| Sent: Wednesday, June 12, 2013 11:04:46 AM
| Subject: Re: [infinispan-dev] New bundler performance
| 
| Hi Radim,
| 
| 1) have you tried to run your tests with the bundling disable in
| jgroups? (UDP.enable_bundling=false)

This attribute is deprecated and is not used anymore. Bundling cannot be switched off in configuration (as far as I know), only by setting the DONT_BUNDLE flag. I could try to disable bundling manually, I will do that.

| 2) how many Stressor threads (assuming radargun) are executing
| transactions in each node? Could you run with a high number of Stressor
| threads like 16, 32, 64 and 128 (with and without bundling in JGroups)?

This is non-transactional, I assume you're asking about operations

 5 threads -> 4300 writes
10 threads -> 4800 writes
20 threads -> 4200 writes
40 threads -> 3700 writes

| 
| About the reads, I don't know if this make sense, but if the
| communication cost is higher the threads are blocked longer and will
| perform less read operations in the same time interval.

The number is computed as number of reads / (time spent in the reads / number of threads). Therefore, it should not be affected by the writes in the direct way from the test (the writes should affect the result in such way only that the node is processing something more or less load in that moment and has less or more time to respond to the read request). But OK, it could be affected in some complicated fashion, let's focus on the writes.

Radim

| 
| Cheers,
| Pedro Ruivo
| 
| On 06/12/2013 09: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).
| >
| > 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.
| >
| > 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.
| >
| > -----------------------------------------------------------
| > Radim Vansa
| > Quality Assurance Engineer
| > JBoss Datagrid
| > tel. +420532294559 ext. 62559
| >
| > Red Hat Czech, s.r.o.
| > Brno, Purkyňova 99/71, PSČ 612 45
| > Czech Republic
| >
| >
| > _______________________________________________
| > infinispan-dev mailing list
| > infinispan-dev at lists.jboss.org
| > https://lists.jboss.org/mailman/listinfo/infinispan-dev
| >
| _______________________________________________
| infinispan-dev mailing list
| infinispan-dev at lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/infinispan-dev