[Spread-users] 1225

[Jonathan Stanton]

On Thu, Mar 07, 2002 at 10:47:06AM +0100, koorosh.alahiari at ids.allianz.com wrote:
> 
> Jonathan,
> 
> I understand your point on flow control. I am
> trying to workout what is happening inside spread
> to account for the considerable difference in
> processing speed between sending & receiving.

It isn't Spread's processing speed that matters. Spread is processing
everything fast enough, that is the reason you are being cut off. The
difference is that your receiving application runs slower then your sending
application. Part of that is that at the OS level, receiving is slightly
more costly then sending because of the work the kernel has to do. There
might also be some other subtle performance differences that matter when you
are processing messages at high speed. 

But the whole point is that Spread is delivering the messages to your
receivng app faster then your receiving app can process them. So the TCP or
Unix domain socket queue between spread and your app fills up and then after
buffering some more messages Spread finally gives up on the client and cuts
off it's socket. So at the time you were cut off, Spread had delivered about
1200 messages to your connection that the receiving app had not yet
SP_received.

The actual spread library code does a small amount of work on receive, and
so it also is more costly then sending by a little bit. But it will
generally always be true that receving is more costly then sending, which
is why you need flow control as you said.

> 
> When a sender is sending spread is receiving
> (from the sender) that is very fast. BUT when spread
> is distributing the message (even to just one client)
> it seems to be much slower (eventhough the whole
> process is still v. fast).

When all you are doing is sending, spread recevies the message from you and
then realizes it can discard it because NOONE needs it. So that is only
doing less then 1/2 of the work. If anyonne needs it, then the message has
to be processed more and then actually delivered to the receiver which will
take at least as long as it took to originally send it. So when both sending
and receiving apps are running it has to be slower as you are doing twice as
much work.

> 
> Is the overhead arising from multicasting (assuming
> my clients don't cause it & there's no net. latency)?
> I would appreciate being educated on this topic.

No, if you are only running one daemon nothing is actually being multicast.

Jonathan

P.S. You do not need to include spread-admin at lists.spread.org on the list of
recipients, the admin address is for mailing list problems not actual
questions, that is what the list is for.

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------