You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Chamikara Jayalath <ch...@gmail.com> on 2006/07/24 09:11:01 UTC
[Sandesha2 ] Improving performance
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
Fwd: [Sandesha2 ] Improving performance
Posted by Paul Fremantle <pz...@gmail.com>.
Chamikara
As an RMS what do we do with the AI? How often do we send AckRequests?
Paul
On 7/24/06, Chamikara Jayalath <ch...@gmail.com> 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 <jn...@gmail.com> 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" < pzfreo@gmail.com>
> > To: "Chamikara Jayalath" <ch...@gmail.com>
> > Cc: <sandesha-dev@ws.apache.org >
> > 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 <ch...@gmail.com> 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
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> sandesha-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> > >
> >
> >
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Fwd: [Sandesha2 ] Improving performance
Posted by Paul Fremantle <pz...@gmail.com>.
Chamikara
As an RMS what do we do with the AI? How often do we send AckRequests?
Paul
On 7/24/06, Chamikara Jayalath <ch...@gmail.com> 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 <jn...@gmail.com> 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" < pzfreo@gmail.com>
> > To: "Chamikara Jayalath" <ch...@gmail.com>
> > Cc: <sandesha-dev@ws.apache.org >
> > 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 <ch...@gmail.com> 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
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> sandesha-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> > >
> >
> >
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@gmail.com> 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" <pz...@gmail.com>
> To: "Chamikara Jayalath" <ch...@gmail.com>
> Cc: <sa...@ws.apache.org>
> 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 <ch...@gmail.com> 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
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
>
>
Re: [Sandesha2 ] Improving performance
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@gmail.com> 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" <pz...@gmail.com>
> To: "Chamikara Jayalath" <ch...@gmail.com>
> Cc: <sa...@ws.apache.org>
> 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 <ch...@gmail.com> 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
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
>
>
Re: [Sandesha2 ] Improving performance
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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" <pz...@gmail.com>
To: "Chamikara Jayalath" <ch...@gmail.com>
Cc: <sa...@ws.apache.org>
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 <ch...@gmail.com> 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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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" <pz...@gmail.com>
To: "Chamikara Jayalath" <ch...@gmail.com>
Cc: <sa...@ws.apache.org>
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 <ch...@gmail.com> 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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Paul Fremantle <pz...@gmail.com>.
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 <ch...@gmail.com> 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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Samisa,
On 7/25/06, Samisa Abeysinghe <sa...@gmail.com> wrote:
>
> Chamikara Jayalath 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.
>
How are you going to chache this? I am interested in figuring out how to
> do that in C, but if you tell me how you plan for Java, that helps.
> Thanks,
> Samisa...
This will be a simple in-memory cache, probably as a property of the
message context. This is not about storing the SOAP envelope (whichiis done
using the StorageManager). The idea here is to simply avoid building the
object model in each handler.
Chamikara
>
> > 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
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: [Sandesha2 ] Improving performance
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Samisa,
On 7/25/06, Samisa Abeysinghe <sa...@gmail.com> wrote:
>
> Chamikara Jayalath 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.
>
How are you going to chache this? I am interested in figuring out how to
> do that in C, but if you tell me how you plan for Java, that helps.
> Thanks,
> Samisa...
This will be a simple in-memory cache, probably as a property of the
message context. This is not about storing the SOAP envelope (whichiis done
using the StorageManager). The idea here is to simply avoid building the
object model in each handler.
Chamikara
>
> > 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
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: [Sandesha2 ] Improving performance
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Chamikara Jayalath 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.
How are you going to chache this? I am interested in figuring out how to
do that in C, but if you tell me how you plan for Java, that helps.
Thanks,
Samisa...
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Chamikara Jayalath 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.
How are you going to chache this? I am interested in figuring out how to
do that in C, but if you tell me how you plan for Java, that helps.
Thanks,
Samisa...
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Paul Fremantle <pz...@gmail.com>.
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 <ch...@gmail.com> 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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Chamikara Jayalath <ch...@gmail.com>.
Great. Waiting for it :-)
Chamikara
On 7/26/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi Chamikara,
>
> Not directly performance related, but I'm fairly sure we could straighten
> the codepath that processes the RM protocol messages (create, terminate
> etc). We discussed it on list a while ago... I'll try and come up with a
> patch.
>
> Thanks
>
> Matt
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: [Sandesha2 ] Improving performance
Posted by Chamikara Jayalath <ch...@gmail.com>.
Great. Waiting for it :-)
Chamikara
On 7/26/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi Chamikara,
>
> Not directly performance related, but I'm fairly sure we could straighten
> the codepath that processes the RM protocol messages (create, terminate
> etc). We discussed it on list a while ago... I'll try and come up with a
> patch.
>
> Thanks
>
> Matt
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: [Sandesha2 ] Improving performance
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi Chamikara,
Not directly performance related, but I'm fairly sure we could straighten
the codepath that processes the RM protocol messages (create, terminate
etc). We discussed it on list a while ago... I'll try and come up with a
patch.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Sandesha2 ] Improving performance
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi Chamikara,
Not directly performance related, but I'm fairly sure we could straighten
the codepath that processes the RM protocol messages (create, terminate
etc). We discussed it on list a while ago... I'll try and come up with a
patch.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org