Re: MOO growth management

• Date: Sat, 16 Mar 1996 18:00:07 PST
• From:
  Christopher Scott Delaney <cdelaney@indiana.edu>
• cc: moo-cows.PARC@xerox.com
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-to: <Pine.HPP.3.90.960316183132.29510A-100000@fohnix.metronet.com>

> Date: Sat, 16 Mar 1996 16:55:52 -0800 (PST)
> From: Jacqueline Hamilton <kira@metronet.com>
> To: moo-cows.PARC@xerox.com
> Subject: MOO growth management
> 
> 
> I'm wondering, mainly from people who've run/managed very large MOOs:  if 
> you were starting over, and you knew your MOO would grow to be so large, 
> what things would you definitely do and not do, to help manage the growth 
> and control lag and db bloat (assuming you want to control it)?   
> 

Here are some of the things we did at RiverMOO when we decided to 
shutdown for a brief period to shrink our db and rebuild:

1) Checked the most used FO's and moved most of those verbs to one main 
public FO. (Although we have still gotten loads of new ones once re-opening)

2) Diskbased $note and news items with FUP (working with some code that 
SunWiz@Sprawl has done for FUP'ing mail).  Also diskbased help.  $spell 
of course was removed long ago.

3) Started regular off-lining of the major mail-lists and made them 
available at a public archive site so people still have access to them.

4) Completely reworked the public geography and made public housing 
options available so that users would be less likely to build tons of 
rooms.  As most MOO wizards know, most rooms on a MOO end up being tiny 
scenery anyway.

5) Installed a room_quota of (currently) 2 for users so they can't go 
over-board with personal room creation.  Users wanting more have to 
petition the wizards and are given extra rooms if a project warrants it.

6) Installed a project system (Multiple Ownership) so that groups of 
players can work collaboratively on coding projects.  The project object 
gets awarded quota that the team members can draw from.  This allowed for 
easier tracking of quota usage for people wanting to work on larger 
projects...while also letting players have a chance to work together as a 
team. (Thanks to Defender for the code)

7) Switched from object based to byte based quota.

8) Started a Quota Review Board and gave them a monthly supply alotment 
that they can dole out as they see fit.  Users were given a @request for 
qrb verb to make it easier for them to request quota while also giving 
the qrb the crucial information needed to make an informed judgement.
This let us project how much and at what rate we would grow in the 
future.  This, of course, doesn't allow for wizardly quota and people 
sending large volumes of mail (the mail was taken care of by monthly 
off-lining).

9) Capped our number of players.  We now run a system similar to Lambda 
in that once the cap is reached, requests are put into a queue and 
processed upon reaping of players that haven't logged in for a set amount 
of time.

There are many more, which included combing through every object on the 
MOO and recycling tiny scenery and things of that nature (Before you 
dismiss that as being cruel, it was an option that the player body voted 
on prior to shutdown).  We also combined a lot of the hierarchies for 
rooms and players to keep things more centralized where possible.
We also renumbered the database and combed through code to fix anything 
using hard object ##'s as reference points.

Hope some of these help.  Just suggestions.
Individual mileage may vary.  This, with some other changes, took us from 
running at 55MB+ in memory to around 25MB now after re-opening in 
December (orjanuary, can't remember which).

--Chris,
Barrett@rivermoo

• MOO growth management
• From: Jacqueline Hamilton <kira@metronet.com>

• Prev: Re: MOO growth management
• Next: MOO systems
• Index: MOO-cows
• Thread: MOO-cows