# MOO growth management

Christopher Scott Delaney (cdelaney@indiana.edu)
Sat, 16 Mar 1996 18:00:07 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    > 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