[MUD-Dev] Benchmarking MUDs

[Ian Collyer]

Adam Martin wrote:
> From: "Lars Duening" <lars at bearnip.com>
>> Chris Gray wrote on Wednesday, September 05 2001, 07:56:10:

>>> Is anyone besides me actually interested in doing this?

>> Well, I must admit that I share Matt's position: it'd be
>> interesting to run some tests provided by somebody else, but
>> developing such tests is not exactly my kind of fun.

>> But I could imagine that Mud admins are more interested in this -
>> after all they are the ones using the drivers, and therefore have
>> a better idea of what would be useful to know.

> If anyone puts together a set of tests, and ensures they are
> documented well enough to be unambiguous (and hence actually
> useful), then I'm sure a lot of people will spring up who are
> ready to start running them. Don't be put off by the
> characteristic silence that often meets questing suggestions on MD
> - suggestions which people do think are a good idea really, but
> assume you know that and hence don't necessarily say so.

> Personally, if a set of tests appears I'll happily run them
> against what we're developing and post the results, if only out of
> general interest.

The performance of any system is only as good as it's weakest link,
the aim (especially if you're the one paying the bills) is not to
remove all bottlenecks, but to equalise them so that no one
subsystem is dragging down the overall performance.

Prime targets for benchmarking MUDs must be...

  - Memory
  - Processor
  - Bandwidth
  - Disk space

The performance of any subsystem can usually be improved either by
throwing money at it (more memory, more/faster processors, bigger
pipe, more/faster disks), by replacing inefficient algorithms or by
some trade off against other subsystems.  You can improve your
bandwidth figures by implementing MCCP, but it'll hurt your memory
and processor stats for example.

Obviously these measures mean nothing without an x-axis to chart
them against, candidates here could be:

  - Concurrent connections
  - Total playerbase
  - No of mobs/rooms/objects
  - Commands received / minute
  etc.

So now we have some stats that we can actually use to compare MUDs
in an almost system independent way (processor utilisation could be
fun).

To make these useful however we now need to relate these stats to
quantities that have some real significance, i.e. cost and response
time.

Now we're in a position to do some serious what-if modelling and get
a better bang for our buck.

IMO the first step that's needed if we truly want to be able to
compare MUD with MUD is to agree on a standard set of stats to
measure.

We need a volunteer to coordinate all the work and report on
progress (I'm way too busy unfortunately), any takers?

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev