[infinispan-dev] To bundle or not to bundle is the question

[Bela Ban]

On 11/11/13 9:27 AM, Radim Vansa wrote:
> On 11/08/2013 05:47 PM, Bela Ban wrote:
>>
>> On 11/8/13 4:15 PM, Radim Vansa wrote:
>>> First of all, I think that naming "old", "new" where 3.2.7 new == 3.4.0
>>> old sucks. Let's use some more meaningful names.
>> Even better: I named the latest bundler "latest" ha ha :-)
>>
>> These names were never supposed to be exposed to the user, only to
>> experts, but +1 on better names... Suggestions ? "default_bundler",
>> "default_bundler2" and "transfer_queue_bundler" ? :-)
> And DefaultBundler is not the default, currently.
>
> So, to come up with some suggestions (from the 3.2.7 code as there are
> all the ideas):
> DefaultBundler -> TimedBundler (bundler_type="timed")
> DefaultBundler2 -> LastWaitingBundler ("last_waiting")
> TransferQueueBunder -> TimedQueuingBundler ("timed_queuing")
> TransferQueueBundler2 -> GreedyQueuingBundler("greedy"/"greedy_queuing")

Thanks for the suggestions I'll change this in 3.5 (branch: 
bundler_perf, currently wip)


>>> Changing the DONT_BUNDLE flag to apply on network communication but
>>> rather to stack processing isn't a bad idea, if it helps performance.
>>> However, changing the flag meaning to be dependent on the bundler type
>>> sounds rather confusing.
>> The idea is that when the battle is over, only one bundler will be used,
>> so we don't need to make this distinction. However, the "old" bundler
>> (which I want to kill at some point) would not perform well when
>> bundling all messages.
>
> By the way, I have accepted that 3.4 "old" is 3.2.7 "new", but looking
> into code, I still see that "old" is the one waiting for
> max_bundle_timeout or until there is enough waiting data... Do I miss
> something? Should this "old" bundler really send all messages immediately?


No, it doesn't. You're right; messages are bundled until the max_size is 
exceeded or the max time has elapsed. This should be slower than "new" 
or "latest" in 3.4.x, why it isn't is something I'll investigate soon.

Perhaps the tests we're running focus on sync, and sync RPCs always set 
the DONT_BUNDLE flag, so bundlig is mostly bypassed. Why "old" is then 
not the same as "new" performance wise still escapes me, but hopefully 
I'll soon know why.

This investigation will be done in 3.5, it isn't critical to release 3.4.1.

> As a last thought for DefaultBundler2 principle (this is the one I find
> most appealing): It seems to me that the thread does not do much work in
> the lock, so the bundle does not grab much messages. The format of batch
> does not specify how many messages will there be in advance, so, instead
> of just adding the message to list (fast), couldn't we keep the
> DataOutputStream and write the message to the stream?

This is something to try out. I updated JGRP-1717 with your suggestion


> Cheers
>
> Radim
>>
>>
>>> Radim
>>>
>>> On 11/08/2013 11:47 AM, Bela Ban wrote:
>>>> I think I'll ignore the DONT_BUNDLE flag on the sender's side if we have
>>>> the right bundler in place. Take a look at [1] and let me know what you
>>>> think...
>>>>
>>>> [1] https://issues.jboss.org/browse/JGRP-1737
>>>>
>>>
>
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)