Any reason to have more MaxThreads than # of CPU Cores ?

[neil upfalow]

Is there any reason to have higher MaxThreads that the number of cpu cores you have?
For example, say there are virtual servers running on a 4 cpu (6cores ea) system. They have traffic that's low, usually a few req/s and mostly for httpd apache anyway. Tomcat jsps n beans execute really fast.
If no virtual server's tomcat could run on more than 24 cores simultaneously, why would i want more than 24 threads as Max.
In reality, it seems apache has 1-2s of work to do after a jsp takes about 100ms to do its total work. I never see more than 20-30 httpd processes running and jsps are so much faster, seems tomcat would not even need 24 threads to back end apaches requests to it.

If i had a tomcat thread max for 100 and a min if 50 ....wouldn't all but 24 threads never even have a chance of executing?
Are threads used for anything else and if so how many?

I would like to pursue a major reduction of total processes running on the hardware and most are tomcat and almost all of them are, in reality, sleeping most of the time....so it seems to me i'd never need more than 24 max.

I'm also curious about reducing threads that need to be killed so if 24 max makes sense for 24 cores then i'd just set min n max to 24 so no cpu time is wasted on thread creation nor destruction.

thanks in advance!

[neil upfalow]

anyone know what the benefits are on of having more threads than cpu cores given they execute and finish their work very fast?

[Tim Holloway]

You usually don't want to have more cluster nodes than CPU cores, but lots of threads are another matter.

Tomcat manages a thread pool, which - among other things - manages HTTP service requests. Every time a request comes in, one of the threads is pulled from the pool and assigned the task of handling it. What's important is not whether it has control of the CPU, but that it's a unit of work. Once you run out of threads, further requests are parked (bottlenecked) at the input request queue until threads get freed up to handle them. If the pool size is too small, all your threads may be waiting for database I/O requests and the CPU could be idle when - given an extra thread or two - it could be processing other requests.

The same applies to other systems as well. For example, I have a webapp or two that use the Quartz Scheduler. Quartz-initiated tasks run under thread pools as well, so if there are more active events than threads, some of them just have to wait.

My test server has a single single-core CPU in it, but a minimal Tomcat runs about a dozen threads.