How many threads is too many?

[peelman]

Hello,

I have written in Java using Eclipse, a turn-based game server. I
accept client connections from an applet and add players to games and
they play cards (poker). Wow, sounds great you must be thinking.
Anyway, for each connection I create 2 threads (one pipe for reading
and one for writing back to the client). Then for each game table I
create a thread too (every 10 players). Then I have a number of timer
threads in different parts of the system. So, I have a lot threads. I
am new to Java (only 3 months deep so far), and for this application I
want to be able to accomodate about 600 clients at once. I figure this
amounts to a maximimum of say 1500 threads.

Now, as a newbie perhaps that is ridiculous. Is this feasible, or is
this just too many threads? Is it just matter of beefing up the
hardware to deal with it or do I need to redesign a bit? In short, how
many is too many?

If I need to redesign then what would be sensible number of threads to
limit my design to?

Thanks in advance,

Neil

 

[John C. Bollinger]

Anyway, for each connection I create 2 threads (one pipe for reading
and one for writing back to the client). Then for each game table I
create a thread too (every 10 players). Then I have a number of timer
threads in different parts of the system. So, I have a lot threads. I
am new to Java (only 3 months deep so far), and for this application I
want to be able to accomodate about 600 clients at once. I figure this
amounts to a maximimum of say 1500 threads.

Now, as a newbie perhaps that is ridiculous. Is this feasible, or is
this just too many threads? Is it just matter of beefing up the
hardware to deal with it or do I need to redesign a bit? In short, how
many is too many?

Yes, 1500 is far too many. As far as I can tell, you are devoting up to
1200 threads to I/O over a single network interface. This can be
reduced to 1 (!) by using selectable I/O. Game events over the whole
server are going to be implicitly serialized by the network interface,
so unless a whopping big load of computation needs to happen for each
event that occurs, it is probably not useful to have more than one
thread to manage all the games together. If you need timed events as
well then one java.util.Timer ought to be sufficient to provide all your
needs. That makes for one more thread.

If I need to redesign then what would be sensible number of threads to
limit my design to?

Three.


John Bollinger
(e-mail address removed)

 

[Neil Collier]

Wow. Thanks. Do you have any advice on resources for 'selectable
I/O'? Any online documentation or examples?

So it is ok to create a socket for each client though? I see no other
way to do this.

And how do I reuse a single java.Util.Timer for _different_ timer
tasks. For example I have a timer firing every 60 seconds to update
client lobbys, another for pausing a game every 5 minutes, and another
for increasing bet amounts every 15 minutes - how can these be
concentrated into 1 thread?

 

[Neil Collier]

For anyone else interested in this topic I just found this
(http://www.ftponline.com/javapro/2004_10/magazine/departments/letters/)
which is quite useful.

 

[Sudsy]

Wow. Thanks. Do you have any advice on resources for 'selectable
I/O'? Any online documentation or examples?

So it is ok to create a socket for each client though? I see no other
way to do this.

That's the way it's done. You just multiplex with a Selector.

 

[Neil Collier]

Can I use this NIO library with SSL too? Currently I use SSL in the
standard Java IO.

 

[Sudsy]

Can I use this NIO library with SSL too? Currently I use SSL in the
standard Java IO.

SSL is operating at a lower level; your application should not care
about the underlying transport protocol. Encryption/decryption should
be invisible to your application, save for the convenience methods like
javax.servlet.ServletRequest#getScheme().
IOW you should just be working with Readers and Writers without regard
to what is happening "under the covers".
I shudder to think how much more difficult servlet programming would be
if I had to worry about whether the request arrived via HTTP or HTTPS.
Why do you think that such sophisticated frameworks (webservers, app
servers, etc.) were developed in the first place?

 

[Esmond Pitt]

For anyone else interested in this topic I just found this
(http://www.ftponline.com/javapro/2004_10/magazine/departments/letters/)
which is quite useful.

This is a non-issue and the article is a furphy. Selectable connect()
does work, you just have to make sure to only select for OP_CONNECT
until the connection completes and not OP_WRITE, and never select for
OP_CONNECT after the connection completes.

The underlying reason is that in BSD select(), OP_CONNECT and OP_WRITE
are the same, and Sun for some reason are going to great lengths to
separate them into OP_CONNECT and OP_WRITE. Why, I don't know.

 

[opalpa]

1500 threads where threads are many-to-one mapped to system threads is
alright from my experience. With 600 connections you might be out of
file descriptors unless you up your system settings.

I'm not sure but linux java may still use one to one threading model
and then 1500 is probably too many. On a solaris machine it's not a
problem from my experience. I've had programs that make, carry out,
and end over 5000 threads per second. Solaris by defualt uses many to
one thread model.

 

[Neil Collier]

I don't understans what you are saying? Usng secure sockets in java
requires using the javax.net.ssl.* package. I use classes like
SSLServerSocket. I have to do this the make my application sockets use
SSL, otherwise they are just standard insecure connections. I am not
program servlets, it is just a compiled Java application executable.
It is not HTTPS requests, it is direct socket communication between
client and server, sending packets designed on my own protocol. Am I
going about this all wrong?

 

[Neil Collier]

that is very interesting. i would be using Windows Server 2003, i
wonder how that stands up to so many threads...? So what kind of
hardware do you use to run this stuff, is it a lot of RAM/CPU power?

 

[Eric Sosman]

1500 threads where threads are many-to-one mapped to system threads is
alright from my experience. With 600 connections you might be out of
file descriptors unless you up your system settings.

I'm not sure but linux java may still use one to one threading model
and then 1500 is probably too many. On a solaris machine it's not a
problem from my experience. I've had programs that make, carry out,
and end over 5000 threads per second. Solaris by defualt uses many to
one thread model.

Just an FYI: The situation depends on which Solaris
version you are using.

- Solaris 7 and earlier: the only available model was
M-to-N, unless you specifically used system-scope
(as opposed to process-scope) threads.

- Solaris 8: The S7 behavior was the default, but there
was an "alternate thread library" that used 1-to-1.
You could substitute this library for the default
at the flick of an environment variable.

- Solaris 9: The "alternate" library from S8 became
the only library: all threads are 1-to-1.

- Solaris 10: Uses the 1-to-1 model.

 

[Esmond Pitt]

Can I use this NIO library with SSL too? Currently I use SSL in the
standard Java IO.

You can use NIO with the JDK 1.5 SSLEngine, but it's pretty tricky.