[MUD-Dev] Persistent Worlds

[Ryan Rhodes]

Jon Lambert wrote:

> > Or do all games actions directly manipulate the DB?
>
> Nope.  I never manipulate the database directly.  It's done as a a
> backend task.  The object manager subsystem stands as an independent
> task.  I use functional partitioning, although the concept is
> similar to components.  Subsystems are inherently concurrent, that
> is once initialized they control their own execution requirements
> via thread pooling.  They also maintain their own message queues and
> interfaces.  Database manipulation is buried within the object
> manager and exist as successive translation layers.  Currently I can
> use any relational database that supports ODBC and SQL 92.  I also
> support various DBMs, the NT registry, and some other experiments.
>
> > If you run strait from disk, what memory caching techniques do you
> > use to improve performance?  Did you implement these yourself are
> > have you used off the shelf software?
>
> I've use both actually and at the same time.  Let me explain.  The
> object manager runs in process space with the rest of the server.
> Theoretically it's decoupled enough to run as an IPC, RPC or piped
> process, although I've never attempted it.  My feeling is and was
> that it would always run best in process space anyways.
>
> The object manager cache is contiguous reusable and fixed memory
> space.  Although fixed it can be adjusted on the fly manually.  The
> cache is maintained by a thread of the object manager. A sweep is
> made of the cache and valid objects that have changed are updated to
> the database.  The sweep also ages _all_ objects by incrementing a
> byte counter.  When that counter reaches 255 the object is marked as
> removable.  When an access is attempted against an object and it is
> found in the cache that counter is set to 0.  If it is not found in
> the cache it is loaded in from the database.  New objects are
> allocated to the first available free location. A free location is
> one not occupied by an object or one where the object counter is
> 255.  This threshold of 255 is also manually configurable on the
> fly.  This is not original.  I borrowed it from the way IBM's OS/390
> manages memory pages.  It's simple and works well.  I borrow a lot
> of old gems from big blue. :-)
>
> Now back to the off the shelf stuff.  As a database backend I've
> used Oracle, Access, and Watcom SQL.  Each of these has their own
> caching mechanisms.  The Oracle server ran on a different machine
> and easily cached the whole database in memory on that machine.  No
> problem there as long as it resides on a high speed network.  My
> Access ran on the same machine and is not configurable (at least not
> the parts of interest to me).  In fact it doesn't help at all,
> wasting memory that I've already carefully managed myself.  OTOH
> Watcom SQL runs as another process on the same machine and you can
> turn off cacheing completely!  The interface is actually a nice
> lightweight IPC implementation.  This is sort of ideal. Not quite
> though.  My homespun database still performs better.

So let me see if I understand what your saying here.  The DB is an
abstraction running under the Object Manager.  To the object manager
it looks as if its all on disk.  Objects may actually be all cached in
memory, but thats handled by the RDBMS.  The Object manager maintains
it's own cache of recently accessed objects in memory as well, storing
and loading this cache to and from the DB as needed, but to the game
the Object Manager appears as if its all in memory.  If I am
understanding you right any objects maintained in cache by the Object
Model would be in duplicate to the version maintained in disk / cache
by the RDBMS?

> One thing to remember when using RDMS technologies is that cacheing
> mechanisms are optimized for generalized access patterns.  In the
> case of some muds, especially those using object relationships,
> these access patterns will almost always be sub-optimal (MOO, Cold).
> This is not so for some other mud designs like (Diku, ROM).  I
> believe I posted an extensive post on the reasons why.  The basic
> Diku design also allows one to leverage referential integrity
> features of RDBMs.

I think I understand what your saying here about access patterns, but
let me ask you this.  In terms of frequency of access, some objects
might even need to be in memory at all times, like the player object
or perhaps the rooms of the central town of the world.  Do you break
your DB abstraction by configuring it to always cache certain data, or
do you put special cases in your Object Manager making it's caching
functionality less generic?  If not, does the caching scheme in your
Object Manager automatically pick up all these items in the most
efficient manner?  Is there a hard (possibly configurable) limit on
how many objects the object manager will cache?

Or, perhaps a better question, do you just shoot yourself in the foot
by trying to guess the most frequently accessed objects in the first
place, rather than letting a nice routine handle it?  It just seems as
though the player object should always be in memory.

Ryan Rhodes







_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev