Re: [jgroups-dev] New flow control protocols
Bela Ban <[email protected]>
| Newsgroups | gmane.comp.java.javagroups.devel,gmane.comp.java.javagroups.general |
|---|---|
| Message-ID | <[email protected]> |
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. #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. > 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