[jboss-jira] [JBoss JIRA] (JGRP-2171) New bundler with max_bundle_size for each destination

[Bela Ban (JIRA)]

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

Bela Ban edited comment on JGRP-2171 at 6/13/17 10:15 AM:
----------------------------------------------------------

{{RemoveQueueBundler}} has performance that's similar to {{TransferQueueBundler}}! On cluster01-08 (8 nodes), the result for TQB was 108'000 reqs/sec/node, and with the following remove queue sizes for {{RemoveQueueBundler}}, I got these numbers (IspnPerfTest):

||remove-queue size || performance ||
|16|98'659 |
|32|108'199|
|64|108'436|
|128|107'774|
|256|107'716|
|512|107'786|
|1024|107'309|
|2048|106'994|
|4096|107'122|
|8192|106'980|

The remove-queue size doesn't seem to have any impact, but this is probably caused by the fact that 100 threads each per node are sending GET requests/responses, and since {{numOwners=2}}, only 75% of all requests go remote.


was (Author: belaban):
{{RemoveQueueBundler}} has performance that's similar to {{TransferQueueBundler}}! On cluster01-08 (8 nodes), the result for TQB was 108'000 reqs/sec/node, and with the following remove queue sizes for {{RemoveQueueBundler}}, I got these numbers (IspnPerfTest):

||remove-queue size || performance ||
|16|98'659 |
|32|108'199|
|64|108'436|
|128|107'774|
|256|107'716|
|512|107'786|
|1024||
|2048||
|4096||
|8192||

> New bundler with max_bundle_size for each destination
> -----------------------------------------------------
>
>                 Key: JGRP-2171
>                 URL: https://issues.jboss.org/browse/JGRP-2171
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0.4
>
>
> The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent.
> This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway).
> The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent.
> This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s).
> We have a main queue, into which the senders write, and a runner thread (same as {{run()}} in TransferQueueBundler), which continually removes messages from the main queue and inserts them into queues for each destination.
> So 1 main queue and 1 queue for each destination.
> h4. Example:
> * {{num_flips}} is 2
> * A message for A is sent, added to the main queue and removed by the runner. It is queued in A's queue
> * Another message for A is sent. Also queued (A's queue: {{A A}})
> * A message to B is sent: A's {{num_flips}} is now 1. A's queue is {{A A}}, B's queue is {{B}}
> * Another message to A is sent. This resets A's {{num_flips}} to 2, B's {{num_flips}} is now 1
> * 2 messages to C are sent. This causes {{num_flips}} for A and B to be 0, so the batches to A (with 3 msgs) and B (1 msg) are also sent
> * No more messages are received, so the batch to C is also sent
> The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*. It is maintained for each destination separately (probably in the queue for that destination).
> h4. Misc
> * Should the sending of batches be delegated to a thread pool?
> * Should the senders add their messages directly to the destination queues instead of the main queue? That would result in less contention on the main queue, but it would also require 1 thread per destination queue, which creates too many threads...



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)