[Home] [Groups] - Message: [Prev in Group] [Next in Group]
18920: RE: [MUD-Dev] Re: TECH: Distributed Muds
[Full Header] [Plain Text]
From: "Derek Snider" <derek@idirect.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 18 Apr 2001 18:52:11 -0400
References: [1]
Organization: Kanga.Nu
According to Vincent Archer:
> Hmmm, no way. If you do so, you waste a lot of capacity. Since
> you're running on a distributed system, you cannot lend one spare
> processor to another zone - well, not in a geographical discrete
> model like the one outlined above. So you end up with processors
> that remain idle 90% of the time, but can support a population 10
> times bigger than what you usually have.
What is wrong with that? It's called "being prepared".
From the many years of server administration I've been involved with,
servers generally run at an average of 80-95% idle.
You always provision for bursts of activity. CPU power is a
relatively cheap asset.
Anyways, my argument was more for off-loading whatever was increasing
load on your zone servers when the player population was high onto the
network handling servers than for increasing the CPU power of the zone
servers.
> systems. One was managing the player (who connected to an available
> player box), which then in turn communicated with a bunch of
> (rectangular) world zones.
I'm not too clear on that UO's model is/was, only what a good working
model would be. The above model allows you to take advantage of a
large TCP Window between the network servers and the zone servers.
If you are concerned about wasting CPU power, you might want to
consider setting up a server cluster (ie: Linux Beowulf Cluster) so
that you can effectively have one huge mega-server that distributes
tasks evenly over all CPUs. I'm not certain that this is the best
solution for high-speed real-time interactive games, but with the
proper configuration, equipment and software, it just might be.
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev