A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
My guess (untested) is the cost of leaving those 15 threads waiting for more work from the Executor's queue is very small
Thread pooling is simply a bet that setup and teardown is worse than holding idle threads. That may or may not be true in different combinations of load and other resource demands.
Originally posted by William Brogden:
I don't see where you have established that there is any good reason to trim currently unused Threads out of the pool. Surely the overhead is minute compared to the cost of creating a new Thread.
How about this - a timer wakes up at one minute intervals and looks at the count of waiting Threads...
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
You've mentioned a couple times that the app uses threads elsewhere. It might even be worth looking to see if pooling would work in those other places, too.
Originally posted by Stan James:
Editing now - you mentioned clients that retry, too. Do you control that code?
I'd bet that creating and destroying threads contributes more to stability problems than leaving a pool sitting idle.
I assume the threads add a performance penalty. I might be wrong though - perhabs 15 threads doesn't use that many ressources.
Originally posted by William Brogden:
My Tomcat installation has a typical configuration where the thread pool for requests has max 150, min spare threads = 25, max spare threads = 75
so you can see that the Tomcat designers don't think having lots of spare threads hanging around is a big problem. This system runs for weeks with only 25 threads actually allocated in the pool.
Originally posted by William Brogden:
A Thread gets a memory allocation when created but that does NOT mean that an idle one is impacting memory use since the operating system can page that memory out.
This app has to run on 128 MB all inclusive (linux OS, JVM ect).
"I'm not back." - Bill Harding, Twister
Originally posted by William Brogden:
What sort of functionality do you have in the Thread pool so far?
Originally posted by William Brogden:
Using 10-20 seconds per job sounds like serious computation is going on - how memory intensive is each job? Having extra Threads started may slow things down if the operating system has to thrash pages in and out.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |