[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

6622: Re: [MUD-Dev] World Persistence, flat files v/s DB v/s ??

[Full Header] [Plain Text]
From: J C Lawrence <claw@under.engr.sgi.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 01 Apr 1998 13:29:05 -0800
References: [1]
Organization: Kanga.Nu
On Wed, 25 Mar 1998 21:12:56 PST8PDT 
Ben Greear<greear@cyberhighway.net> wrote:

> The crucial part you are missing here, is how to do the snapshot?
> You still have to pass (copy) the data, either through a pipe or
> socket or something.  It would probably be about as quick to just
> write it to disk...  Of course, I could be wrong...

In the uniw world the standard approach would be either to use streams 
(not supported by Linux), or to use a shared memory ring buffer.  Both 
work.  Each has it advantages.  The other standard forms of IPC
(socketc, messages etc) are not terribly fast.  

The underlieing reason and advantage for using a seperate thread or
process to do your DB backups is performance.  Your main
thread/application does not have to halt or impede its service in
order to do the backup. In the case of seperate processes, this is
done by having the backup_process buffer the data, taking it as fast
as the main process can supply it in times of low-load, and waiting
about cheaply tapping its virtual foot when load it high.  For
threads, careful control of thread priorities and blocking controls on
the thread handle this.  In both cases the main interface to the
application is no longer dependant on the rate or overhead of the disk
IO, and (ideally) is not slowed by the rate that the data is flowing
to disk.

--
J C Lawrence                               Internet: claw@null.net
(Contractor)                               Internet: coder@ibm.net
---------(*)                     Internet: claw@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...