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
USER PID %CPU %MEM VSZ RSS SHRD STA TIM COMMAND
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
dramatically.
>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 - Me@Null.net | Genius may have its limitations, but stupidity
http://www.van.ml.org/~greerga | is not thus handicapped. -- Elbert Hubbard
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST