Re: Circlemud design issues

From: James Turner (turnerjh@XTN.NET)
Date: 04/26/98


George <greerga@CIRCLEMUD.ORG> writes:

> >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.
>
> Even 20 MUD wouldn't take that much processor time.  If they all took 5%
> each, constantly, (a really large MUD), then they could keep the computer
> busy without degrading service.

It's not just an issue of processor use, it's an issue of disk use.
As I said; just run updatedb at the same time as booting your mud, and
see how much longer it takes.  As for muds using 5% -- as you know,
they tend to spike quite high at some times (force all save, spam
tracking, etc).  Though they usually do run low, they can at times
cross 5% quite easily, depending on the code and the machine.

> >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
>
> Straw man argument.  No, I'm arguing that most places will have better than
> I do, and those that don't have better (the 486/50 example), will still run
> quite fast.

In the previous post, you validated your own argument by providing one
example where it wasn't a problem.  Specific to general is not a valid
argument technique.

> >a nice, large amount of resources.  What about people who share
> >servers with 20 to 30 other muds?  Or 5 or 10?
>
> 20 MUDS taking 5% processor time constantly would happily co-exist.

Again, it isn't just processor time.  It's also disk contention.
Besides, as I said above, muds don't run at constant percentages.

> >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
>
> It moves files closer together, you select 'Full Optimization' instead of
> just 'Defragment Files'.

So you're saying that servers should go down regularly so that they
can go through full optimizations like this?  Full optimization does
not do quite what you think.  It removes space between files, as well
as defragmenting them.  It doesn't move them near to each other based
on directory structure.  Very old defrag programs did do something
similar, but with drives as huge as they are nowadays, it has been
left by the wayside.  Reorganizing the entire directory and file
structure of a 2 gig drive (or 4 512meg partitions) isn't something
you can in a coffee break.

> >that.  And 3k text files won't be fragmented -- but they will be
> >scattered.
>
> In some programs, (Central Point's Defrag did) they will place all files
> and their subdirectories together on the disk.  That keeps them
> unfragmented and close together.  This only applies to Win95, other systems
> will make a good attempt to keep things close.

Other systems will try, perhaps, but that's no guarantee.  Further,
since these text files would tend to grow (particularly eq and
aliases.  If these files were packed together at any time, then the
later growth would lead to fragmentation (since say a file in the
middle of two others would be bigger and need more sectors).  ext2fs
and other unix file systems optimize for performance on the whole, not
for specific applications.  Assuming that it will take care of a
single process's needs is hopelessly naive.  Sometimes it is necessary
to help the OS along a bit.

> >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
>
> For $40 a month, mudservices.com will put you on a Pentium II with 128 MB
> of RAM or a dedicated Pentium 200 with 64 MB of RAM.  They're probably IDE,
> but they have enough RAM to not matter.  mud.gator.net has K6-166MHz and
> up.  I just checked their site.

Not true.  $40 a month gets you:

250 Megs of Disk Space
Full Domain Name Support (yourmud.mudservices.com or yourmud.com)
  for E-Mail addresses and WWW Site address
4 Ports (ie, working mud, testing mud, builders port, etc)
65 Max TCP connections
Telnet Access (one account - multiple logins up to 7 accepted)
14 Meg RAM quota
10 accounts on one Option A Server
P-II 233 with 128 Megs RAM running Linux.

Straight from their web site.  You share this system with up to ten
other muds.  To get a dedicated system, you have to pay about $170/month.


> >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,
>
> Bad memory, I'd tell you but the post.queensu.ca archive doesn't search at
> the moment.  So send your $40 to mudservices or mud.gator and get yourself
> a K6 or Pentium II.  I'll keep running it on my 486/50 laptop also.

Again, you misread their site.

--
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