Subject: MOO Questions.

From: [email-masked] (Ted Wallace)
Date: Sun, 21 Feb 1993 07:17:32 -0800

Hi, I'm on the administration of a MUSE currently considering a server
change, and MOO is on the list of possilbities.  Aside from the normal
difficulties of your averaged TinyMU* player moving to MOO, I have concerns
about MOO...

One: How efficient is MOO wrt to softcoding everything?  That is, since new
things are added into the database, rather than the server code, it might
be less efficient (MUSH and MUSE have commands based in the server and it
takes C hacking to add new stuff).  That is - I've seen considerable server
lag on LambdaMOO (~86 people were on that night). What kind of Machine is
Lambda on?  And is large server lag just an accepted consequence of MOO?
How long would a typical delay be on a typical machine for 40 users, and
what is the max delay on a typical machine for a max number of users of,
say, 80 people?

Any additional insights you might give to efficiency/stability/ease of use
issues would be GREATLY appreciated.

Respond to me, or feel free to respond to [email-masked].

Falryx @ LambdaMOO
F'lyr  @ DragonsFire MUSE

---

From: Pavel Curtis <[email-masked]>
Date: Sun, 21 Feb 1993 20:44:41 -0800

> Date:	Sun, 21 Feb 1993 07:17:32 -0800
> From:	[email-masked] (Ted Wallace)
> 

LambdaMOO is running on a Sun SPARCstation IPX with 128 Mbytes of physical
memory and 1.4 Gbytes of local disk space.  The database file is currently
weighing in at about 70 Mbytes on disk.

The vast majority of lag on LambdaMOO is caused by the large number of
long-running, CPU-intensive, background tasks running there, especially related
to the role-playing game system some folks wrote.  Tasks created to execute
player commands usually finish in a small fraction of a second, not
contributing to lag hardly at all, even with many (~80) users.  The difficulty
comes when tasks that require a lot of compute-time get started.  The server
currently uses a fixed timeout of 30,000 ticks or 15 seconds for `foreground'
tasks (like player commands) and 20,000 ticks or 5 seconds for `background'
tasks (forked or suspended).  Long-running tasks (e.g., ones that search the
entire database for various kinds of information or perform very complicated
computations) usually use up all of their assigned time each time they get a
chance to run, locking out executions of play commands for that time.  The many
tasks spawned by the RPG system are frequently of this sort and thus slow down
interactive response.

The answer to your specific questions about response with 40 or 80 users,
therefore, almost entirely depends on what's being done in the commands those
users are typing and how many and what kinds of tasks are being done in the
background.  Absent any background tasks, normal MUDding commands (say, emote,
page, text-editing, programming, sending mail, digging, describing, etc.)
induce essentially no perceptible lag.  On a SPARCstation 2 or similar machine
(25 MIPS?  I can't remember) with sufficient physical memory (approximately 1.5
times the size of the DB file on disk), a server running only such commands and
handling 50 or so users should be able to provide delays under a second.

Of course, sometimes the Internet itself provides lag time; these predictions,
of course, assume no such added problems.

> issues would be GREATLY appreciated.

I have no experience running any other kind of MUD server, but I have been told
that the LambdaMOO server code is better written, more easily read and
modified, and much more stable than most others.  LambdaMOO commonly runs for
weeks at a time without being rebooted and has had no crashes attributable to
the server code for many months (unless I'm forgetting something, but I don't
think I am).

Also, because the LambdaMOO server is at the heart of my own professional
research interests (applications of social virtual realities to
non-recreational settings), I am constantly on the lookout for ways to improve
the performance, reliability, and functionality of the server.  While I am very
busy, and thus do not (alas) have the time to make new releases of the code as
frequently as I would like, I do try to respond very quickly to reports of
critical bugs in the code, usually providing fixes via email within hours of my
hearing about the problem.  Thus, I think the server is generally pretty
stable.

Of course, all of the above commentary is coming to you from the author of the
code and not an independent user, so you must take it all with a grain of
salt.

	Pavel/Haakon/Lambda