MOO-cows Mailing List Archive
Re: HTML + MOO + NT = ???
On Wed, 5 Feb 1997, Don Mitchell wrote:
> If you think your MOO or ColdMUD is going to be a very big world, NT
> would be a better choice than W95. In theory, you should be able to
> tune the network I/O and use a few I/O threads to get more throughput.
> I wonder if anyone has experimented with this? A 'thread per head"
> doesn't seem wise (i/e/, one thread per connected player), but having a
> few of them doing the network I/O will practically never block. You
> could also try using async I/O (which W95 doesn't do).
My guess is that for the large majority of MOO applications, a single
separate thread doing network I/O would be more than sufficient, provided
that the thread waits simultaneously on sockets to be ready for I/O and
for server network queues to be ready for I/O. As a rule, general MOOing
is a low-bandwidth activity, and the server isn't particularly
network-bound. A side benefit of threading the network I/O would be
eliminating the delay before output starts--if you have a task that does
lots of output you don't see any until it's not running any more.
Of course, using a MOO as a webserver is a much different animal, and
there having multiple threads might well be quite effective.
Windows Sockets under '95 do support what the Winsock *calls* asynchronous
I/O; however this just means that messages are posted to the application
when sockets are ready for read/write. Since messages aren't processed
preemptively like Unix signals are, this is unhelpful.
> And of course, if you have a
> multiprocessor PC, multi threading gets you some parallel processing as
> well. But read/write blocking is the main reason to do this. If you
> think the world is REALLY going to be huge, you probably need Server NT,
> which unfortunately is expensive. I know ftp servers running SNT deal
> with 600 connections or so, but I don't think any MUD on the net is that
> big. Furry gets close to 400 on their P-100 machine (they're running
I don't think that workstation or server will have much impact on the
performance of a MOO. As I understand it, the only substatial difference
is the size of timeslice given to applications; the longer timeslice keeps
performance from degrading at high load from zillions of context
switching, at the price of losing some responsiveness. But with a MOO, a
single thread is using all the CPU, so it's not so much an issue.
Actually, the responsiveness of workstation might be an asset--initial
network output happens that much faster, so overflowing the internal
network buffer is that much less likely.
Of course, using NTW 4.0 as a MOOserver with more than 10 users is a
violation of the EULA, but that's a different story entirely.
Ultimately, I think MOO size is clearly not currently limited by network
performance, but rather by the speed at which it can execute MOO tasks.
Seems to be the case with LambdaMOO itself.
> Anyway, with NT or UNIX, it would be fun to hear about experiments with
> multi-threading and async I/O..
Agreed. There are other areas that could benefit from multi-threading on
SMP machines. Database loading is one--the slowest thing is verb-code
parsing and that would parallelize easily. Checkpointing is another.
I've also had ideas for ways to structure a server so that it could break
past the one-processor-executing-tasks barrier while maintaining
appearances that it was happening...
ResComp Senior Network Support Technician (SNST)
Home Page: http://www-personal.engin.umich.edu/~cunkel/
"Invisibility is in the eye of the beholder."
Subject Index |