workload simulation (was: Re: [MUD-Dev] MMORPG/MMOG Server design)

[Damion Schubert]

From: ceo

> I believe you're talking about three problems:
 
>   1. simulating a "heavily loaded" system (to run continuously in
>   parallel with all other simulations)

[ deletia ]

> Number one is, well, either "very hard" or "pretty easy". If you
> need to test anything that depends upon the realism of the
> connections (e.g.  testing your front-facing socket-listening
> stuff), then it's hard. Good example of a problem that I know some
> games failed to discover (because they didn't do this kind of
> testing until too late):

>From a designer's point of view: in the past, checking basic 'load
balancing' usually meant logging on a gazillion faux clients who
would move and talk - move, because it is usually the most common
piece of traffic, and talk because it's usually easy to code and put
in cute messages that amuse you.

This is fine, provided that movement is your bottleneck.  However,
over the years, I've seen different parts of the game be the slow
one.  Monster AI and pathfinding, as well as spawning, can have huge
impacts on CPU time and bandwidth, but if your load testing is just
putting faux characters on an empty world, that won't be factored
into your results.

Similarly, some systems (such as guilds) work fine with no apparent
server slowdown when there are only 2-3 guilds with 2-10 people in
them (as there usually is when the coder is testing his own work),
but fail cripplingly when put in a (hopefully) beta or (less
optimally) live environment, and two dozen 200 person guilds spring
up.  I believe in UO, the team discovered that those larger guilds
could, in fact, crash the server doing basic housekeeping functions
back in the early days. =/

Thirdly, CPU and bandwidth varies largely based upon whether it's
day one or day one hundred.  On day one, you have more people in an
area touching fewer spawners - this is a quite different pattern
than the rest of the life of the game (aside from wipes).  Most
companies never address this, though - they either never realize it,
or feel that a one-time problem that lasts for about a week isn't
worth an elaborate code solution.

--d
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev