[MUD-Dev] Re: MUD-Dev request rejected

[J C Lawrence]

On Mon, 22 Nov 1999 14:25:01 -0600 
Greg Miller <gmiller at classic-games.com> wrote:

> I recently ran across an article linked from news.com discussing a
> study on memory vs. disk performance. They found that databases
> designed to be kept entirely in RAM were at least an order of
> magnitude faster than disk-based databases that had sufficient RAM
> available to keep the entire database in cache. 

This is hardly surprising as the cache manintenance code and object
reference overhead in a cacheing DB become significant when the
entire DB is in cache.  

Which is faster:

  Having all of your money in your pocket at all times (given a big
enough pocket) in one great wad, or having all of your money always
neatly sorted by bill size and intended use in your wallet (given a
big enough wallet)?

The overhead of keeping your wallet sorted can be extreme.  The
problems of handling a great undifferentiated wad of cash can be
entertaining.

A few of the real concerns in DB design here are:

  working set size

  possible maximum working set size

  working set change characteristics (spikes, valleys, how rapidly
  the cache might get flushed.invalidated etc)

  VM performance/page fault overhead

  performance gains from object proximity

Its not an obvious answer.  Yes, there are advantages to keeping
everything in RAM always -- until you exhaust physical RAM and your
DB page thrashes VM to death due to the fact that your working set
is spread over more pages than you can fit in physical RAM at any
one instant.

So, you decide to get clever and do object migration and migrate
your objects at runtime across your VM system in attempt to ensure
some level of proximity for the members of your working set (ie
reduce the number of VM pages required to store your working set).
And of course the overhead for this is non-zero both in watching and
computing the object moves and in the extra level of abstraction
required for every object reference so that pointers aren't hard
tied...  So you decide to be even more clever and figure out
<whatever> which has <some other> expense.

In fact, and this is the cute and very scary bit, with very very
good cacheing code and utterly optimal working sets a disk-based DB
can, in certain cases, beat the performance curve of an in-RAM DB
purely due to avoiding VM page check overhead.

There's no panacea here.  Yes, in-RAM DB's can be atrociously fast.
So can on-disk DB's.  Alex Molitor and Marcus Ranum (mostly Marcus)
both demonstrated this fact in great detail for MUDs (cf Uber and
Unter) and shocked the heck out of a bunch of people at the time.

Which is better for you depends on your load, what happens to your
load at its extremes, what performance curves you expect from those
extremes, and what resources you can guarantee to the server at
runtime (given everything else running on the machine).

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev