From: James Rogers (jamesr@best.com)
Date: Mon Dec 09 1996 - 14:46:59 MST
At 05:03 PM 12/8/96 -0600, you wrote:
>> Since the the more advanced simulations will suck more server
>> time, it would make sense that we have some way of allocating
>> resources according to people's ability to effectively use them. It might
>> even prove an interesting exercise in a completely
>> laissez-faire system - people can gain credits for building a cool addition
>> to the world and charging admission
>Ah, the quota battles begin! Quota on LambdaMOO was handled, last time
>I checked, by the ARB - the Architecture Review Board, I think it was.
>Ironically, arbitration is handled by the mediation system, which is
>totally unrelated to the ARB.
>
>Again from personal experience, I'd say there are three important things
>to remember about server-side resources:
>1) When a better solution comes along, enforce it.
> If LambdaMOO wasn't using their old obsolete systems it would cut
>quota
>usage in half and lag would go down 95%.
>2) Keep only active areas in active memory.
> On LambdaMOO, EVERYTHING is kept in RAM. As opposed to WorldMOO,
>where
>things like help systems can be kept on disk.
>3) Track the usage of actual resources.
> LambdaMOO used to have an object quota; you got twenty objects. This
>encouraged huge monolithic programming; there was no restraint on the
>number of methods on an object or how long those methods were.
>Object-oriented programmers were penalized because they could only use
>one object.
> By the time they switched over to tracking bytes, the damage was done.
>All the core systems were these ridiculously large monoliths - I believe
>that an advanced old-style room cost 20K of OVERHEAD.
> They still don't track CPU usage and as a result, command-line orders
>can take from 8 to 60 seconds to execute, with around 20 being around
>average. This is because the system is so OVERLOADED with these
>gigantic monoliths.
>
>Overall, I'd say introduce a system where:
>1) A guy gets X bytes of RAM, Y bytes of disk space, and Z CPU
>cycles/day.
>2) The core architecture is laid out by a programmer who breathes the
>programming language being designed in. Java is not C or even C++; make
>sure the world-builder knows that.
The core architecture cannot be done in Java. Server-side Java is simply
too slow, even on a fast machine, to handle more than a relatively small
number of clients. Fortunately, a number of methods and systems are
emerging that allow Java objects to interface with C/C++ software at
runtime. Obviously, there will be significant requirements that require the
inclusion of Java, but they should only be used where absolutely necessary.
The type of systems we are discussing will probably require a semi-custom
server side engine of fairly high complexity. AFAIK, there is no existing
engines or models of this type that would adequately meet the needs of this
project.
How many simultaneous users are we targeting? This makes a big difference
in terms of architecture.
-James Rogers
jamesr@best.com
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 14:35:53 MST