I am trying to do some planning for NFC Chat and I noticed that it apparently launches two threads per connected client. If I run under Linux and use native threads, this seems to limit my server's ability to support clients. I think Linux (2.2.x) supports 1024 processes or threads as a max. So, if I want to constrain the server to half of that, I am at 256 clients on the ChatServer.
Can anyone comment on this thinking? Did I understand the code right?
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, Linux's native threads stink. You'll get much better multi-threaded performance using green threads (JDK 1.2.2). If you are on a box with more than one processor, then MAYBE the native threads would be beneficial, but I am yet to actually try an experiment with this.
Next, regarding the thread usage by NFC, there should only be one thread per client plus one global "dispatcher" thread. It used to be 2 threads per client in the older days (are you running an older version perhaps?)
Finally, you might want to look into the NBIO (non-blocking IO) package for Java: http://www.cs.berkeley.edu/~mdw/proj/java-nbio/. It uses native methods to implement non-blocking IO. Presumably, this would allow NFC to handle an order of magnitude (or something) more connections per server than it does now. Adding support for NBIO is on my list of things I'd like to do to NFC in the future...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-12-12
Hi Taso,
Will the new I/O in jdk 1.4 remove the need to use the berkeley native non-blocking IO?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Will the new I/O in jdk 1.4 remove the need to use the
> berkeley native non-blocking IO?
It should. But unfortunately, it's not a matter of flipping a switch; the architecture will require some amount of reworking. Ideally, it would be nice to set it up such that the IO mechanism is configurable, so one can switch between the 1.4 style and the old style.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to do some planning for NFC Chat and I noticed that it apparently launches two threads per connected client. If I run under Linux and use native threads, this seems to limit my server's ability to support clients. I think Linux (2.2.x) supports 1024 processes or threads as a max. So, if I want to constrain the server to half of that, I am at 256 clients on the ChatServer.
Can anyone comment on this thinking? Did I understand the code right?
Thanks,
Charlie
A few comments..
First, Linux's native threads stink. You'll get much better multi-threaded performance using green threads (JDK 1.2.2). If you are on a box with more than one processor, then MAYBE the native threads would be beneficial, but I am yet to actually try an experiment with this.
Next, regarding the thread usage by NFC, there should only be one thread per client plus one global "dispatcher" thread. It used to be 2 threads per client in the older days (are you running an older version perhaps?)
Finally, you might want to look into the NBIO (non-blocking IO) package for Java: http://www.cs.berkeley.edu/~mdw/proj/java-nbio/. It uses native methods to implement non-blocking IO. Presumably, this would allow NFC to handle an order of magnitude (or something) more connections per server than it does now. Adding support for NBIO is on my list of things I'd like to do to NFC in the future...
Hi Taso,
Will the new I/O in jdk 1.4 remove the need to use the berkeley native non-blocking IO?
> Will the new I/O in jdk 1.4 remove the need to use the
> berkeley native non-blocking IO?
It should. But unfortunately, it's not a matter of flipping a switch; the architecture will require some amount of reworking. Ideally, it would be nice to set it up such that the IO mechanism is configurable, so one can switch between the 1.4 style and the old style.