[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance?



jerry.westrick at ch.abnamro.com wrote:
> 
> I was thinking about your performance.
> Could it be that network latency (round trip time)
> is holding back your system?
> 
> Could it be that your communications protocol is
> "synchish" instead of "asyncish"?
> 
> Let me explain what I mean:
> 
> "Syncish"
> TIME   Client X  xmlBlaster
> -----  --------  ----------
>   ?         ?         ?
>   ?         ?<--msg 1-+
>   ?       proc1       ?
>   ?         +-msg1ok->?
>   ?         ?<--msg 2-+
>   ?       proc2       ?
>   ?         +-msg2ok->?
>   ?         ?         ?
>   ?         ?         ?
>   V
> 
> Above you wouldn't send the second message until
> the client finishes processing the first message.

With CORBA our update() method which calls back to
the client is declared 'oneway', we are not
waiting for a response (asynchish).

With RMI and XML-RPC the callback is "synchish".
(A todo is here to implement some dispatcher thread
with a thread pool and timeout check)


> Another method more "asyncish" would be:
> 
> TIME   Client X  xmlBlaster
> -----  --------  ----------
>   ?         ?         ?
>   ?         ?<--msg 1-+
>   ?       proc1       ?
>   ?         ?<--msg 2-+
>   ?         +-msg1ok->?
>   ?         ?<--msg 3-+
>   ?       proc2       ?
>   ?         ?<--msg 4-+
>   ?         +-msg2ok->?
>   ?         ?         ?
>   ?         ?         ?
>   V
> 
> Using the second scheme the Client has a second msg
> to process immedeately upon finishing his first message,
> without waiting for a message to get to xmlBlaster
> and returning.
> 
> The system we use, fills the socket until it says a
> write would block.  And then adds more to it as soon
> as there is room in the buffer.  In this way the
> client constantly has msgs to process with out waiting
> for network responses.
> 
> This is a major drawback to RPC systems, here another
> diagram:
> 
> TIME   Client X  xmlBlaster
> -----  --------  ----------
>   ?         ?         ?
>   ?         ?<--msg 1-+
>   ?       proc1      NOP!
>   ?         +-msg1ok->?
>   ?        NOP!       ?
>   ?         ?<--msg 2-+
>   ?       proc2      NOP!
>   ?         +-msg2ok->?
>   ?        NOP!       ?
>   ?         ?         ?
>   V
> 
> The NOP! stands for wait and do Nothing!  Typical of RPC,
> send-of a call and wait for the answer (NOP).
Currently with RMI and XML-RPC: yes
with CORBA: no

> 
> Could it be that network latency (round trip time) is
> holding back your system?
Yes could be possible.

Do you have any numbers from you MOM implementation
how much the performance gain would be?


Marcel
-- 
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org