ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <>
Subject Re: [Sandesha2 ] Improving performance
Date Mon, 24 Jul 2006 13:14:59 GMT
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;

For the threadpool, I think we should use Axis2's threadpool.

+1 for the improvements.


----- Original Message ----- 
From: "Paul Fremantle" <>
To: "Chamikara Jayalath" <>
Cc: <>
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 <> 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
> "Oxygenating the Web Service Platform",
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message