Chamikara As an RMS what do we do with the AI? How often do we send AckRequests?
Paul On 7/24/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi Paul,Jaliya, All, The current implementation works as follows. If the AcksTo endpoint is anonymous an Ack is sent in the response channel of every request message. If AcksTo is a real endpoint, we use the AcknowledgementInterval policy to decide the acking interval. In this scenario if the request message has an AckRequested header an async ack is sent immediately. Else we wait the time amount defined by AcknowledgementInterval policy before sending the ack as a standalone message. If the Sandesha2 Sender find any application messages going to the same endpoint before this time interval is passed, it will piggyback the waiting ack in this message. I guess one way to support the Pauls long running RM scenario is providing a high value for the AcknowledgementInterval policy, if we provide a additional policy to decide the piggybacking interval (which may be a percentage as paul mentioned). Chamikara On 7/24/06, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: > Hi All, > > I agree with Paul. We can get this optimization for request/response single > channel scenarios where we can always send an ack in response messages and > also for others we can wait before sending ack for sometime. Remember, when > we did the interops with IBM they had this implemented :) > See. Msft does the same; > http://wcf.netfx3.com/content/IntroductiontoReliableMessagingwiththeWindowsCommunicationFoundation.aspx > > For the threadpool, I think we should use Axis2's threadpool. > > +1 for the improvements. > > Thanks, > -Jaliya > > > ----- Original Message ----- > From: "Paul Fremantle" < [EMAIL PROTECTED]> > To: "Chamikara Jayalath" <[EMAIL PROTECTED]> > Cc: <[email protected] > > Sent: Monday, July 24, 2006 4:53 AM > Subject: Re: [Sandesha2 ] Improving performance > > > > Chamikara > > > > Firstly nice review. > > > > I guess the other question is how often and how we do > > acknowledgements. The overall number of messages will affect the > > performance, because each on-the-wire message has a high overhead. > > > > So: > > > > 1) if we can piggyback acknowledgements then I assume that saves time > > over sending them direct. > > 2) if we can avoid acking every message, we save time - UNLESS, this > > causes the RMS to get "anxious" and start AckRequesting. > > 3) Of course if we piggyback ackRequests then we also save time. > > > > So it seems to me that we can be efficient by implementing the > > following approach: > > > > I think we need a "window". Lets take an example, where we configure > > the system to ack every 60 seconds. > > > > We want to have a short window of say 5-10 seconds before the 60 > > seconds are up (maybe the last 10-20% of the acktime?). In this window > > the RMD should try to piggyback an ack back. That way we don't send > > too many acks, but we try to get one piggybacked before we run out of > > time. > > > > The RMS should implement the opposite. If it doesn't get an ack and it > > needs/wants one, maybe it should wait a short period of time before > > creating one and see if it can piggyback an ackrequest on a message. > > > > I guess the other problem is that we have two different scenarios to tune > > for: > > > > The "short sequence" scenario is usually someone's first view of RM > > and there is usually just one or two messages in the sequence. In that > > case we want a piggybacked ack on the each response if possible. Then > > there is a "long running" RM scenario where two parties are going to > > send lots of messages and then we only want to add an ack every once > > in a while, and just nack if we notice a single missing message. > > > > Maybe we need a switch and a default. I.e. we default to being > > optimised for short sequences, and then when customers move into > > production we recommend they consider tuning it by setting the "long" > > sequence optimisation on. > > > > Paul > > > > On 7/24/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: > >> Hi All, > >> > >> I went through the Sandesha2 code to find out any places we can modify > >> or > >> change to improve the overall performance. I thought following > >> improvements > >> would be useful. > >> > >> 1. Caching initialized messages > >> > >> Currently MessageInitializer.initialize() methods get called multiple > >> times > >> for the Same message context (for example in Handlers, Invoker, Sender > >> etc > >> ). Everytime this is called the RM object model get built out of the SOAP > >> envelope. But it will be better if we can cache this object model once it > >> is > >> built. > >> > >> 2. removing unnecessary repeated calls to the Storage Manager > >> > >> There are times where the same data get obtained from the Storage > >> redundantly. This should be avoided and data should be cached and reused > >> whenever possible. > >> > >> 3. Making Sender and Invoker Thread pools > >> > >> Currently Sender and Invoker are single threads. This is a bottleneck. > >> These should be made thread pools to concurrently invoke and send > >> messages. > >> > >> 4. msgNoPresentInList(String list, long no) method in Application > >> message > >> processor. > >> > >> This method is called for every application message. Current > >> implementetion > >> has to be corrected to support a 'long' number of messsage numbers and > >> the > >> implementation has to be optimized. > >> > >> 6. correct and optimize 'string to ArrayList' methods > >> > >> SandeshaUtil.getArrayListFromString (String str); > >> SandeshaUtil.getArrayListFromMsgsString (String str); > >> > >> > >> 5. Cleaning code > >> > >> This includes remove unnecessary or repeated object creations (which i > >> found in some places :-) ), removing commented code, and adding some more > >> Javadocs, and some refactoring. The basic idea is to improve the > >> readability > >> of the code. > >> > >> > >> Do you guys see any other areas that can be modified or changed to > >> improve > >> the performace of the system ? > >> > >> > >> Chamikara > >> > >> > >> > > > > > > -- > > Paul Fremantle > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > http://bloglines.com/blog/paulfremantle > > [EMAIL PROTECTED] > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > >
-- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
