JuanE <[EMAIL PROTECTED]> writes on 2 August 2000 at 16:37:36 GMT
>
> I agree with you both (Jay and Michael), at least partially. I agree that
> altough what Jay proposes will work, it is too much computation and that a
> simpler round-robin (after picking initial position) would suffice.
>
> My comment is that in the event of a down server, the simple round robin
> will flood the next server in the chain with twice the load of the others.
> Jay's solution does not do this (at a high computational cost).
>
> What I proposed earlier is just one of *many* solutions that addresses the
> flood problem at a lower computational cost.
>
> Jay, I agree with you that selecting the same server many times in a row is
> not an issue. This is guaranteed by the Law of Averages (for you math
> wizzes out there, the Law of Large Numbers).
Sounds like making repeated random picks is the way to go.
If no server is down, your one random pick will handle the mail (same
cost as picking random starting point for round-robin).
If a server is down *and you hit it*, you pay the cost of a second
random pick. This is slightly expensive, but you only pay it when
you need it. It's cheaper in elapsed time than trying the next server
and having it refuse the connection due to overload, for example. And
it spreads the load more evenly.
On the third hand, if the servers can manage their incoming
connections intelligently (say with tcpserver :-) ), the one after a
down one in a round-robin, while it will get hit a lot, can refuse
some of the connections, which will then go on to the next after it.
So you aren't really constrained to running all your servers at less
than 50% capacity, and the one after the down one won't actually melt
down.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
