Re: Circlemud design issues

From: George (greerga@CIRCLEMUD.ORG)
Date: 04/24/98

On Fri, 24 Apr 1998, James Turner wrote:

>Yes, but until a player logs in, their data isn't cached, nor is their
>directory entry, so there is overhead in this.  Unless you cache them
>all, you can only be guaranteed of having a particular file cached
>after the player has logged on.

Once they've logged in, it will remain cached if they lose link or save.

>As for your server keeping 40 meg cached -- how many muds are running
>on it?  Is there a webserver on it?  How many hits?  I can point to
>any number of particular, high-end machines that will support a point
>-- it still isn't proof.

One MUD, two Quake servers, Apache, and GDB.

Mem:   79652K av,  78188K used,   1464K free,  19568K shrd,  10480K buff
Swap:  66492K av,     32K used,  66460K free             29992K cached
ds       10445  0.0 12.1 10336  9676   856 S   0:04 /home/ds/ds/bin/circle5 -q
ds       10444  0.0  9.6  8280  7652   680 S   0:01 gdb bin/circle5 -d src
quake      129  0.0  8.9 10264  7112   568 S   0:00 ./squake -dedicated 16
quake      134  0.0  7.1 25100  5732   448 S   0:00 ./qwsv +gamedir qwring

   Server uptime: 1 day 12 hours 25 minutes 5 seconds
   Total accesses: 14574 - Total Traffic: 302.7 MB
   CPU Usage: u1.05 s1.46 cu0.1 cs0.05 - 0.00203% CPU load
   0.111 requests/sec - 2420 B/second - 21.3 kB/request
   1 requests currently being processed, 8 idle servers

The one-time not-in-cache will only happen when they first log in.  Every
subsequent access such as losing link or saving will remain cached by the
OS unless you don't have much memory, in which case you can expect
everything to be slow anyway without cache.

>> There's a difference here.  Putting all your headers into one file gives
>> virtuall no benefit with quite a few disadvantages.  Here, we're getting
>> all the advantages of ASCII player files and lose very little.  It's a ffar
>> better tradeoff to have ASCII pfiles than a unified header.
>"All the advantages" -- a slight change to binary organization can
>gain those advantages as well.  Further, your arguments clutter the

Once you do that you have increased the binary complexity so much that it
would be better with ASCII pfiles anyway.
* Separate binary pfiles so you can compress people not online
* An offline/online player editor.
* vi is your friend (or pico in my case)
* No more complex than loading/saving the world.
* No slower than loading/saving the world and trivial in comparison.

There's probably more against but I have yet to hear something new from
your arguments.

>> So we extend build_player_index() to scan for gold also, since it already
>> scans for all the player names.  Trivial.
>You're saying run build_player_index() every boot, and have it scan in
>each of the text files?  Even the inactive ones?

Yes, you'd be scanning the inactive players in a binary file too.

>A hundred or so ascii files in the world file is one thing.  But
>thousands of players, each maybe 3k (which I doubt, taking into
>account descriptions, equipment, aliases... unless these are separate
>files).  You're saying this won't bring normal servers to a crawl

Sammy has said they will be.

>during boot?  It'll thrash the disk like mad, particularly in a
>heavily used environment.  Worse, the OS's cache won't be able to

No it won't, because when you're done with a file, it can dump the memory
for the next one.

>predict the next file to read, so readahead won't help (unlike binary,
>where it can readahead in the binary file itself).

Sure, but when you're done, _all_ of those files will remain cached until
something else tosses them out.

>Again, you're running on a devoted system, with no other muds loaded,
>on a highend system.  Not all muds in the real world are so lucky.

The Pentium 233MMX did it in .9 seconds, my 486/50 did it in 6.7 seconds.
That's not a horribly long time considering the 2.5 megabytes to parse and
that it compiles the entire MUD in 8 minutes, 20 seconds.

>That is why I said the numbers weren't very relevant -- not just
>because of the file sizes, but also because of the server type.

They're relevant because at least one person does have my setup.  Many
people will have better also.  Those that have worse, will not slow down

>We can argue this on any level you want; file system, disk cache,
>physical disk, whatever.  A big issue is fragmentation resulting from
>their being a large number of ascii files.  Since you untarred the
>circle source at one time, there will be a fair amount of physical
>nearness on the disk of the files.  That will reduce disk time a fair
>bit because seek times won't be an issue.

Big, awful 9 ms hard drive seek times?  100 random seeks at worst would be
900 ms.  Not much when you consider that the worst case.  Or if you like
the extremes, 1000 players would be 9000 ms at absolute worst (ping ponging
hard drive head).  If you have that many players, the rest of your MUD
takes much longer boot anyway, such as the world. (And you should probably
run 'defrag' on your hard drive too.)

>Try this.  Run updatedb at the same time as booting the mud.  Do it on
>a freshly rebooted system.  Maybe have netscape loading at the same
>time, and circle compiling.  That will give you an environment more
>representative of the real world.

Actually, if you noticed earlier, Chris Powell (I believe), has a Pentium
(dual?) II with 384 MB of RAM.  Quite a bit larger than mine, and most of
the MUD hosting services give AMD K6/200MHz or better.

>Now, as for using spares -- are you saying the ascii pfiles should
>have tags like "Spare01: " and such?

If people (or patches) don't rename them, yes they will. Realistically,
every spare should be renamed to something more descriptive but if the
person or patch doesn't put anything more descriptive, we fall back to the
default.  This way they save the information and can rename the field later
(including code to recognize both of course)

>That way they end up uneditable.  There will have to be something lower
>that char_data dealing with all new char_file_u entries.  They will need
>entries somewhere in the interface between the ascii pfiles and the
>char_file_u translation.

Or so you think, at the moment, I doubt it.

George Greer  -   | Genius may have its limitations, but stupidity | is not thus handicapped. -- Elbert Hubbard

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST