views:

186

answers:

3

Is there any way to determine how many threads can specific JVM + Application Server combination handle? The question is not only about web application request serving threads, but also about background threads.

A: 

This really isn't something that you can find out purely from the Java VM. It is more of a hardware/OS limitation than anything specific to the VM. The best way to find out this answer is to test with a large number of threads and see where you start to see a performance dropoff. See also this devx discussion.

jsight
Thanks. The link was helpful.
Superfilin
+1  A: 

This is really dependent on the particular hardware you are running with (number of CPUs, amount of memory, etc.) and also dependent on the OS (Solaris vs. Windows) since the underlying threading is dependent on the OS-provided thread management. It also depends on the application and app server itself, since the amount of resources each thread consumes is application-dependent.

Ken Liu
+2  A: 

For all practical purposes this is situational, it really does "depend".

  • what are the threads are doing?
  • how much memory do they each need?
  • how much garbage collection is going on?
  • how much memory have you got?
  • how many CPUs have you got?
  • how fast are they?

JEE App Server applications tend not to create threads themselves. Rather you configure thread pools. I've never yet been in a situation where the ability to create 10 more threads would solve a problem and some app server limitation prevented me from doing so.

Making performance comparisons between different App Servers is very non-trivial and the answers tend to brittle - ie. small changes in the type of work can produce different answers.

Why are you asking the question?

djna
The reason I ask is beacuase I want to make some asyncronous processing inside web services. The original request will, of course, be served by a thread from a thread pool defined by application server, but then that thread spawns, let's say, 5 additional threads to do the work. So, the total number of threads that server will potentially need = number of request serving threads * number of worker threads per request + certain number of background threads. That number can be quite large. I just wonder how the JVM may behave in such scenario before I implement something :).
Superfilin
1) Threads are processing web service requests and internally accessing data base and other web services2+3) Today with sequential processing they spend 5-6MB/request 4) Memory available: 2GB5) 1 CPU6) depends on back end system response
Superfilin
Many application servers have architected ways of allowing some way of spawning of additional worker threads in a controlled manner, asynchronous job queues etc. Using those you should be able to get a balance between normal service threads and additional worker threads. It may well be that if the web service is doing very heavy work and "submitJob, getJobResult" operation pair may work well.
djna