From cctrieloff at redhat.com  Tue Sep  2 18:45:15 2008
From: cctrieloff at redhat.com (Carl Trieloff)
Date: Tue, 02 Sep 2008 14:45:15 -0400
Subject: [Rhm-users] Re: [Rhemrg-users-list] RHM Performence
In-Reply-To: <4df0fedf0809020851o33064118ufd8bcfc6c5876aef@mail.gmail.com>
References: <4df0fedf0808270612s59f81c28pf2079c78d2e5c612@mail.gmail.com>	
	<1219848810.3198.29.camel@rolf>	
	<4df0fedf0808270853o41444088g3ea0156e0cd4c5df@mail.gmail.com>	
	<4df0fedf0808270858g6fe4b52di805753536274a11d@mail.gmail.com>	
	<48B58937.7010401@redhat.com>
	<4df0fedf0809020851o33064118ufd8bcfc6c5876aef@mail.gmail.com>
Message-ID: <48BD89BB.8080308@redhat.com>

mark yoffe wrote:
> Hi everyone
>  
> thanks for your help so far , your suggestions were very useful
>  
> i have implemented all your suggestions , here is a list of the 
> implemented suggestions
>  
> 1 - parallel send and receive - using threading
> 2 - accept mode in Rx - disable - (done through - 
> subscriptions.setAcceptMode(1))
> 3 - accept mode in Tx - disable - looks like this is the defuslt as 
> far as i saw but.. (done through adding 'arg::acceptMode=1'
>        to the session.messageTransfer() )
> 4 - use async message transfer ( done through the AsyncSession 
> interface) - was used in your examples already
> 5 - SetFlow mode - unlimited bytes and Unlimited messages , and 
> disable window mode
>     ( this was done through -
>        subscriptions.setFlowControl(SubscriptionManager::UNLIMITED, 
> SubscriptionManager::UNLIMITED, false);)
>  
> it seems suggestion 5 only had affect if it was done before the 
> subscribe command - this is not mentioned anywhere
> if this is true and not only a coincidence - please note this 
> somewhere in the user manual
>  
> i tried making this changes on java api all went well except for 
> feature 5 which the system did not agree to accept unlless
> the command came after the subscribe command ( the synch through a io 
> exception)

Thanks will forward to doc


>  
>  
> Anyway all these suggestion had a nice affect the point to point test  
> (request response) got better by 30%
> which means it now takes 7 seconds instead of 10 seconds
>  
> on the three way message train ( 1->2 2->3 3->1) it had less affect 20%
>  
> this is still very far from the resalts i recieve from the PerfTest
> can anyone think of any other reasons for this
> Any other useful suggestions

will take another look for you in a bit.
Carl.