[MUD-Dev] Re: OT: Java multithreading performance

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Mon May 18 09:59:23 CEST 1998


[Vadim Tkachenko:]

:I have the logging routine implemented in such a way that it accepts the
:messages and prints... well, makes them available to the final logging
:device, in the thread runninh with background priority. When I ran this
:est, I had to disable all that stuff because the log was becoming silent
:after some number of threads (don't remember the exact number, though).

Understood. Determining what the absolute number of threads it can support
is academically interesting, but not real useful. Determining the number
of MUD-server-like threads that it can support is more useful. Your
result is closer to that. So, if a server design in Java intends to use
a thread per client, and each client should have an open socket, then at
least on Linux, the socket-per-process limit is likely to be reached before
any inherent Java limit. Of course, there is still the CPU power limit,
which is stressed more by a bunch of Java byte-code than it is by native
code. Somewhere inbetween would be Java compiled to native code. Another
limit is that of the system's speed in processing TCP/IP data - that may
well consume more of the CPU than any processing in the server!

When I get my new computer all set up, so that I can move it to this desk
and permanently shut down this one, I'll finish off the writeup on my
AmigaMUD bytecode, and likely post it here. (Speaking of bytecode.) My
environment here is all messed up, which is why I've been fairly quiet.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA


--
MUD-Dev: Advancing an unrealised future.



More information about the mud-dev-archive mailing list