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]
