[MUD-Dev]

Juha Lindfors jplindfo at cc.helsinki.fi
Tue Jan 26 11:40:51 CET 1999


At 10:19 25.1.1999 -0500, Elis Pomales wrote:

> The current dilemma, is whether I should use threads on a per player
> (per socket) basis, or implement a polling loop and queue player
> commands,

I'm using the thread per player method.


>handling one command per player per loop cycle. The problem with having a
>thread per player is the context switching overhead. The problem with the
>polling loop is that I have to check each player to see if they have
>input. (There is no select() in Java.)

There are some statistics available on the web concerning heavily threaded
Java servers.

InfoWorld Labs tested an on-line stock trading system on different JVMs and
operating systems. Big Iron can handle a big bundle of transactions, PCs
did a little less.

<URL:http://www.infoworld.com/cgi-bin/displayTC.pl?/980914analysis.htm>


JavaWorld had the results of a VolanoMark test which is a stress test for a
chat server written in Java. Some JVMs managed to handle even 900
connections although if I read the tables right, at that point there was
only roughly 1 message getting through per thread per second.

<URL:http://www.javaworld.com/javaworld/jw-08-1998/jw-08-volanomark.html>


>PS. I would still use more threads, one for NPC's and one for the game
>world.

Nod.

>PSS. Is having 100+ threads really that bad? (I would think so)

Looking at these statistics it seems to me it's not necessarily a disaster.


--
Juha






More information about the mud-dev-archive mailing list