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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
