[Spread-users] More Performance Issues/Questions
paul at pauldemarco.com
Wed Dec 22 12:09:40 EST 2004
>From reading past mailings I will try to recap what my understanding is:
Basically, if the token goes around the ring several times and nothing
is sent, then the leader (it doesn't matter who it is for the purpose of
the implementation), will hold onto the token for hurry_timeout to stop
the token from being past for no reason. All other daemons also know
that the leader is holding it because they have calculated the exact
same 0-traffic situation. If any of them need to send data, they are
supposed to be able to request the "holding" stop. Only if no one does
this, then hurry_timeout will occur, and the token pass around as normal
(possibly being held again).
It does appear from people that there may be a bug in requesting the
leader to release the token before the timeout occurs when others have
data to send. Although I have no basis to state this myself, and never
looked at the code :)
You can change the hurry_timeout to something much less, just realize
that you'll be sending the token that much more often, 24/7 around the
clock. Its design was simply to save bandwidth when no one was doing
anything. Under heavy or continuous load this would not occur.
One posting questioned if possibly the code to request the token during
this holding period wasn't working properly, but there didn't seem to be
any response to it, or further investigation.
In any event, changing the hurry_timeout to an acceptable delay, will
solve your problem, and remember its only when the load is non-existant
for several trips around the ring (which given can occur probably within
fractions of a second of idling) if on a LAN.
Mike Perik wrote:
>Shouldn't the leader give up the token before going into the select?
>What's the purpose of the leader?
>Is this a bug or just a side effect of the implementation?
>Seems to me that this should be documented especially for situations where you
>have 1 talker and many listeners. The leader needs to the be talker.
>Couldn't there be some kind of agreement made in the ring that whoever is
>talking a lot becomes the leader? Or the leader could determine that someone
>else out there is doing the talking and I'm not so I'll give up the token a
>On Tuesday 21 December 2004 01:27 pm, Mike Perik wrote:
>>Ok, I think I've found the problem.
>>In the spread.conf I had two machines. The leader is always the first
>>machine. The leader is the one who holds onto the token and he'll hold
>>onto the token for the Hurry_timeout. Since the first machine in the
>>configuration file is the client machine he holds onto it for Hurry_timeout
>>seconds. It goes into a select with the Hurry_timeout and since the
>>server/publisher is waiting for the token to publish the client waits the
>>whole time (Hurry_timeout or 2 seconds by default) since there is nothing
>>to read. I'm assuming the server queues up all the messages that are
>>being sent and when it gets the token it sends them all.
>>I switched the order of the two machines in the configuration file around
>>and the problem essentially went away.
>>If I'm correct on how this is working, I have a couple of questions?
>>What if I have two servers that are publishing data at a high rate and
>>neither of them are the "leader"?
>>What kind of delay is this going to cause?
>>If I have 20-30 spread daemons in my segment how much additional latency is
>>there going to be?
>>I believe this is why the spmonitor shows the "last" which was the server
>>having a high number of retransmits.
>>Is this a known issue?
>>How would I best design my system around this problem?
>>Spread-users mailing list
>>Spread-users at lists.spread.org
>Spread-users mailing list
>Spread-users at lists.spread.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Spread-users