[MUD-Dev] Text Parsing

[J C Lawrence]

On Wed, 9 Jun 1999 16:21:28 -0700 (PDT) 
Matthew Mihaly <diablo at best.com> wrote:

> Actually, on that note generally, I have read some talk on here,
> in the past, about how some of your servers can handle a LOT of
> users online at once without having speed problems. 

I've scaled using simulated users under very artificial conditions
and a rather minimal world to just over 700 simultaneous players on
a fairly mid-range box.  Performance at that point really became a
kernel function due to poor MT work on IO under Linux (single lock).

> How the heck do you manage that? 

Careful design mostly.  I know what things cost, how much they cost,
and how often I absolutely have to do them.  This is one of the few
areas where all that CS math you (should have) done in grad school
comes in *really* handy, but is still not really necessary.

> We use an interpreted engine (which I realize is inherently
> slower)...

That's a dangerous and often massively misleading assumption.
Interpreted languages need not be either slow or performance
bottlenecks.  LP and BatMUD demonstrate this rather clearly.
LambdaMOO demonstrates rather clearly that this _can_ be a problem
given poor design and implementation.  BatMUD shows part of the
other side: that given good and careful work, the performance hit is
a strawman.

> I suspect that our player routines (mainly movement) tend to be
> significantly more complicated than most muds (again, mainly
> movement, due to the enormous number of database searches that
> need doing to check for all sorts of stuff everytime someone
> moves)...

I smell sloppy thinking here.  Yes, there is good reason for having
motions trigger cascading state checks.  I do it myself, and I
suspect do it to a far greater degree than you do (I've counted over
2,000 state checks resulting from a single most-pessimal move).  No,
there is no reason for those state checks not to short circuit
extremely cheaply in the common cases.  A heck of a lot of the time
you can determine far more cheaply whether or not you need to make a
variety of checks, than you can do the checks themselves.

> ... but I don't think our mobile ai is particularly complicated,
> although currently mobiles do things regardless of whether players
> are in the room (such as wander about, sleep to heal if wounded,
> gather items they find, etc).

Conversely this is a point where I currently spend massive numbers
of cycles.  Its rather ugly.

> We think we're going to have to convert to a UO-style system where
> we split upt he land geographically and run the different areas on
> different servers. That SEEMS, to my not-very-knowledgeable-self,
> to be something that we shouldn't have to do just to get past 100
> players online (i figure I can squeeze out another 33% performance
> from careful optimization).

The above simultaneous simulated user load was on a low end
AlphaStation with 192Meg of RAM (forget CPU # and clock) whose
performance is roughly equivalent to a P300 with 64Meg RAM (Alpha
code and data density is very low).  That box got me up to 700
users, at which point it essentially cratered.  Given a decent PC
base, I see little reason you shouldn't be able to pass the 1,500
point modulus Linux kernel issues (such as the single IO lock).

Aside: When in performance doubt, don't use normal SCSI or IDE
storage devices under Linux.  Go for one of the DAC960 based
hardware RAID cards.  Linux'es SCSI stack is rather poor and the
DAC960 drivers bypass the SCSI stack and implement their own (much
faster) layer.  Given RAID 0/1 you can run at nominal SCSI buss
speed with very very little effort.

> Can anyone tell me if this seems normal to you?

Get a profiler.  Get some performance statistics.  Find out where
you are spending your time.  Determine if that is actually
necessary, or whether implementation or architectural changes can
remove the requirement.  Repeat this process several times until
there are no obvious bottlenecks, or any remaining bottlenecks are
either fundamental and uneconomical to remove, or implicit in
systems you don't control (eg kernel, device drivers, external
latency etc).

--
J C Lawrence                                   Home: claw at kanga.nu
---------(*)                Linux/IA64 - Work: claw at varesearch.com
 ... Beware of cromagnons wearing chewing gum and palm pilots ...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev