Re: [jgroups-dev] New flow control protocols

On Sep 14, 2010, at 11:50 AM, Bela Ban wrote:

> 
> 
> Galder Zamarreño wrote:
>> Does it make sense to have UFC but not MFC in the config? And viceversa?
> 
> Yes.
> 
> #1 UFC but not MFC: an app does mostly unicasts, e.g. Infinispan's DIST 
> mode. Note that if unicasts or multicasts are marked with NO_FC, then 
> *both* UFC and MFC are bypassed; this is useful for example when using 
> synchronous RPCs.

Yup, Infinispan's already using that.

> 
> #2 MFC but not UFC: an app rarely uses unicasts.
> 
> 
> 
>> If neither make sense, the config should be abstracted to have 
>> something like which underneath uses UFC and MFC:
>> 
>> <FC2 max_credits="2M" min_threshold="0.6">
> 
> FC2 as a wrapper could be done, but I don't see the advantage over 
> having 2 protocols. On the contrary: FC2 would have to delegate (up and 
> down) messages to either MFC or UFC, and would have to delegate things 
> such as configuration, lifecycle, JMX/probe etc as well.

I think FC2 only makes sense if UFC and MFC did not make sense indepedently. Since they do, I don't think it's worth it. It would confuse users more IMO.

> 
> 
>> On Sep 10, 2010, at 5:40 PM, Bela Ban wrote:
>> 
>>> FYI,
>>> 
>>> I've added 2 new flow control protocols: MFC (Multicast Flow Control)
>>> and UFC (Unicast Flow Control). They're an implementation of [1], which
>>> is about splitting the FC functionality into 2 separate protocols.
>>> 
>>> The advantages are that this simplifies the code, the code becomes more
>>> maintainable, that we can enable unicast or multicast flow control
>>> individually, that I could remove some coarse grained locking, and that
>>> I created helper classes, e.g. to manage sender or receiver credits,
>>> which can be unit tested individually, apart from the use in the 
>>> protocol.
>>> 
>>> The downside is that we now have MFC and UFC instead of just FC.
>>> 
>>> My goal for performance was that MFC and UFC should be about the same as
>>> FC, but not slower.
>>> 
>>> This morning, I ran a quick perf test [2] on a 4 node cluster, with 4
>>> nodes (all senders) sending 1 million messages (of varying size) each.
>>> The numbers are MiBs/sec/node.
>>> 
>>> The numbers for 4 nodes are:
>>> 
>>> Size FC MFC/UFC
>>> 
>>> 1K 135 135
>>> 2K 145 145
>>> 4K 145 145
>>> 8K 130 131
>>> 
>>> 
>>> The numbers for 8 nodes are (2 processes per physical box):
>>> 
>>> Size FC MFC/UFC
>>> 
>>> 1K 72 73
>>> 2K 83 85
>>> 4K 87 93
>>> 8K 107 113
>>> 
>>> 
>>> As can be seen, performance is about the same, or even slightly better
>>> with MFC/UFC when running 2 perf JVMs / physical box. However, the
>>> second test on 8 nodes is to be taken with a grain of salt, as the 2
>>> JBMs/box are competing for CPU and the network, and therefore we don't
>>> saturate the network (bandwidth)...
>>> 
>>> To use the new folw control protocols, replace
>>> 
>>> <FC max_credits="2M" min_threshold="0.6" />
>>> 
>>> with
>>> 
>>> <UFC max_credits="2M" min_threshold="0.6" />
>>> <MFC max_credits="2M" min_threshold="0.6" />
>>> 
>>> I will change the configs shipped with JGroups after some more testing
>>> and updating the documentation.
>>> 
>>> 
>>> [1] https://jira.jboss.org/browse/JGRP-1154
>>> 
>>> [2] http://community.jboss.org/docs/DOC-11594
>>> 
>>> -- 
>>> Bela Ban
>>> Lead JGroups / Clustering Team
>>> JBoss
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> -- 
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Javagroups-development mailing list
> 

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Javagroups-development mailing list