4 ms·

The thrust of my argument is merely that one thread for every connection is bad. (Minecraft happens to use two per connection, but that doesn't change the funda

The thrust of my argument is merely that one thread for every connection is bad. (Minecraft happens to use two per connection, but that doesn't change the fundamental argument.) You are correct that the problem is not directly due to thread resource usage, but to the additional resources attached to each thread. I was able to raise the heap size, but not able to get past around 600 connections on my 32-bit x86 machine. NIO/MINA is the right answer on Java. If you are using Erlang, well, I would suppose you would not need a Java-based solution. :3

KirinDave 16y ago
"NIO/MINA is the right answer on Java." I think my point, which admittedly is only informed by the work of some brilliant people, is that your point is not supported by data gathered on modern hardware with modern operating systems running a modern JVM. At least, not in all cases. With care and some tuning, people can get extremely good performance out of the thread-per-connection approach. Please check the document linked in the parent to this thread (http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html http://paultyma.blogspot.com/2008/03/writing-java-multithrea...) What's more, even the systems that are very good at this do not use something like NIO, epoll, or select (as anything other than a very buried implementation detail). Erlang, for example, doesn't restrict you to the kind of model that raw NIO does. NIO is a fine thing for what it is, and a potential building block for many things, but it's not a very compelling as a server framework. MINA is a better suggestion, but still not a universal catch all for these sorts of problems. I'm not trying to say, "NIO is never right, tpp is never wrong." I'm just saying your categorical statement is not always correct. Making that statement is wrong, and it's misleading, and I don't think the problem you found was really due to the unavoidable overhead of the threading.
- MostAwesomeDude 16y ago
  Okay. I concede.
  - KirinDave 16y ago
    I didn't even know a person COULD enter these words into an internet text box. I thought the internet itself would reject them. ;) I salute you, sir.

KirinDave 16y ago

"NIO/MINA is the right answer on Java." I think my point, which admittedly is only informed by the work of some brilliant people, is that your point is not supported by data gathered on modern hardware with modern operating systems running a modern JVM. At least, not in all cases. With care and some tuning, people can get extremely good performance out of the thread-per-connection approach. Please check the document linked in the parent to this thread (http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html http://paultyma.blogspot.com/2008/03/writing-java-multithrea...) What's more, even the systems that are very good at this do not use something like NIO, epoll, or select (as anything other than a very buried implementation detail). Erlang, for example, doesn't restrict you to the kind of model that raw NIO does. NIO is a fine thing for what it is, and a potential building block for many things, but it's not a very compelling as a server framework. MINA is a better suggestion, but still not a universal catch all for these sorts of problems. I'm not trying to say, "NIO is never right, tpp is never wrong." I'm just saying your categorical statement is not always correct. Making that statement is wrong, and it's misleading, and I don't think the problem you found was really due to the unavoidable overhead of the threading.

MostAwesomeDude 16y ago
Okay. I concede.
- KirinDave 16y ago
  I didn't even know a person COULD enter these words into an internet text box. I thought the internet itself would reject them. ;) I salute you, sir.