George <greerga@CIRCLEMUD.ORG> writes:
> >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.
Assuming it isn't displaced. Write buffering won't keep it in memory
if it isn't read from.
> 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.
So we should exaserbate disk performance issues on machines that are
fully loaded? Or we should take even more resources from servers?
If muds start monopolizing disk access, then servers will be dragged
to the ground. Let's try to avoid making sysadmins mad. Not everyone
owns their own machine -- in fact, most muds run in cooperative
environments. If we code like circle is the only program running,
then we're just heading for trouble... not to mention pissing
sysadmins off.
> 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.
The binary changes I suggest (to even out the differences between
ascii and binary) aren't that complicated. Certainly less complicated
than maintaining two different types of save systems.
> >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.
Once again, scanning in a binary file is orders of magnitude faster
than scanning a huge number of textfiles. Moreover, the larger the
mud, the slower this will be. The cost will be prohibitively
expensive. Scanning each pfile at boot is ridiculous.
> >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.
A file isn't in cache til it has been read at least once. The OS
can't predict that because you read files in Aardvark's directory that
next is Aaxel. In a binary file it can.
> >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.
There's no guarantee of them being there for long. In fact, a good
disk cache will cache what is used frequently, and use space beyond
that to cache other files. The ascii pfiles won't be read that often,
but when they are, particularly at boot, it will have overhead.
> >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.
Do what I said in my previous message -- run a few disk intensive apps
at the same time. updatedb is good, as is loading something like
netscape. Make sure nothing is cached.
> >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.
You're arguing that because one system is fast that all other systems
won't suffer performance issues? That's the most innane thing I've
every heard. You're running on more or less a _dedicated_ server with
a nice, large amount of resources. What about people who share
servers with 20 to 30 other muds? Or 5 or 10?
> 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.)
The average seek time is just that -- average. Half of all random
seeks take longer, half shorter. Pingponging would be arouns 18000ms.
There's no defrag for linux (well there is but it's never used in a
server environment), and even win95's defrag doesn't move files to be
closer together -- there's no effective heuristic or algorithm to do
that. And 3k text files won't be fragmented -- but they will be
scattered.
> >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.
Most mud hosting services aren't quite that highend yet; Pentium 150s
seem to be average. And their disk subsystems (which this will push
much more than cpu) aren't anything other than low-end IDE (ie, space
over speed). Chris Powell doesn't run this setup as he mentioned in
another post. And the vast majority of servers don't run that,
either. And even if they did, that kind of hardware would be in place
for a reason, and it would be likely a heck of a lot more else was
running at the same time.
> >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)
Which will get a large number of people complaining that a patch
doesn't work completely. Though I personally think only bug fixes
should be distributed as diffs (to help get people more involved in
knowing what's going on in their code), I don't see that happening for
a long time. And until it does, people will want patches to do all
the work necessary, so patch makers will need to work on both fields.
> >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.
Every field that needs translated from a tag like "Blah: value" in an
ascii pfile has to go somewhere. That means code to support
translating it into the correct structure. I've not looked at Sammy's
ascii pfiles, but I assume something like this is done (similar to
envy):
structure ascii_entry {
const char *tag;
int type; /* string, integer, special */
int size; /* max str length, sizeof(integer), -1 for special */
int offset; /* offset from base of char_file_u
};
...
{"Blah", TYPE_INTEGER, sizeof(int), offsetof(char_file_u, blahfield)},
...
So adding an entry wouldn't be difficult unless it is a special type,
which would add a it more work. Modularizing isn't hard; but there is
no way to avoid having to set up some kind of mapping from strings
into the char_file_u structure. Actually, the same structure above
could be used for saving, also.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| 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