[jboss-jira] [JBoss JIRA] (JGRP-1405) TP: pool of hashmaps for message bundling

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668862#comment-12668862 ] 

Bela Ban edited comment on JGRP-1405 at 9/4/12 11:00 AM:
---------------------------------------------------------

I looked at the TransferQueueBundler and using an algorithm like the following [1]:
- As long as there are messages in the queue, add the messages to the hashmap
- When the size of the accumulated messages is greater than the bundle size, or the queue is empty --> send the bundled messages

This essentially sends *single* messages immediately, and batches messages which are queued up, so we don't need a max_bundle_timeout or DONT_BUNDLE message tag any longer. This also simplifies the code.

Having said that, I wrote my own test to measure performance of just the TransferQueueBundler. With the default (1 million 1K messages and 20 adder threads), I got around 600'000 message/sec on my workstation.

The use case is multiple producers, but only *one* consumer (which then bundles and sends the bundled messages).

Then I tried the RingBuffer from the Disruptor project, and (with a BlockingWaitStrategy) only got ca 400'000 messages/sec. I have to look into this further, because I expected more, but perhaps this is a misconfiguration...

[1] http://mechanical-sympathy.blogspot.com/2011/10/smart-batching.html
                
      was (Author: belaban):
    I looked at the TransferQueueBundler and using an algorithm like the following [1]:
- As long as there are messages in the queue, add the messages to the hashmap
- When the size of the accumulated messages is greater than the bundle size, or the queue is empty --> send the bundled messages

This essentially sends *single* messages immediately, and batches messages which are queued up, so we don't need a max_bundle_timeout any longer. This also simplifies the code.

Having said that, I wrote my own test to measure performance of just the TransferQueueBundler. With the default (1 million 1K messages and 20 adder threads), I got around 600'000 message/sec on my workstation.

The use case is multiple producers, but only *one* consumer (which then bundles and sends the bundled messages).

Then I tried the RingBuffer from the Disruptor project, and (with a BlockingWaitStrategy) only got ca 400'000 messages/sec. I have to look into this further, because I expected more, but perhaps this is a misconfiguration...

[1] http://mechanical-sympathy.blogspot.com/2011/10/smart-batching.html
                  
> TP: pool of hashmaps for message bundling
> -----------------------------------------
>
>                 Key: JGRP-1405
>                 URL: https://issues.jboss.org/browse/JGRP-1405
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.3
>
>         Attachments: BundlerStressTest.java
>
>
> We currently have 2 message bundlers i TP: the default bundler which adds messages to a hashmap and, when full, has the sending thread serialize all queued messages into one and send it, and the transfer queue bundler, which has the sending thread place a message into a blocking queue and the dequeuer thread collect and send the bundled messages.
> The disadvantage of the default bundler is that everyone has to wait adding messages to the hashmap, until message bundling has completed. OTOH, the transfer queue bundler blocks all sending threads when the blocking queue is full.
> Let's create a third bundler, which behaves like the default bundler, but uses a *pool of hashmaps* rather than one. This way, when one hashmap is full, the other sending threads don't have to wait until bundling is complete, but can continue adding their messages to a different hashmap.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira