[MUD-Dev] Question about multithreaded servers
Emil Eifrém <emil@windh.com>
Emil Eifrém <emil@windh.com>
Mon Jan 31 10:37:18 CET 2000
> -----Original Message-----
> From: J C Lawrence [mailto:claw at kanga.nu]
> Sent: Sunday, January 30, 2000 8:22 PM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] Question about multithreaded servers
>
[snip]
> Most current OSes do not handle large numbers of threads well,
> meaning that if you player base grows, you'll start running into
> scaling problems with your OS as your thread count rises
> proportionally and your OS starts gagging.
Very true. For a hobby project, however, this may not be that big of a
problem. For my own project, I have chosen a combination of OS and language
that's probably as slow and non-scalable as it goes (Linux + Java) and
simple tests show that I can do at least 2500 concurrent connections before
the performance impact on the rest of the server is too high.
And this is on fairly modest hardware, running an operating system that
doesn't scale all that well in this particular domain (yet) and with the
added layer of a Java virtual machine. And my threading model penalizes me
with twice as much threads as connections [no asynchronous I/O in Java :(].
A server written in C or C++ can probably do *much* better than this. So for
the hobby project, I think it may be a reasonable choice with one thread per
connection.
As a quick FYI (I know others on the list work on Java-based
implementations), IBM just published a very interesting paper called "Java,
threads, and scheduling in Linux" that discusses these issues:
http://www-4.ibm.com/software/developer/library/java2/index.html
Dan Kegel has a good page on the "C10k problem," or how to handle over
10'000 concurrent connections in Linux. I think it's in the library but
here's a shortcut:
http://www.kegel.com/c10k.html
---
Emil Eifrem [emil at windh.net]
Java Developer, .windh AB
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list