Michael Sinz wrote:
>
> On Mon, 31 Aug 1998 14:14:21 +0000, Per Widerlund wrote:
> >
> >After reading and hearing about the performance that can
> >be gained by using thread pools, I made a simple thread
> >pool implementation.
> >
> >On my Linux machine (PII266/64) running jdk1.1.6-v2 (sbb),
> >I got a 0.15 ms/thread reduction in thread start-up overhead.
> >(The test was iterated 60000 times.)
>
> I have been doing thread pooling for about as long as I have
> been doing Java. The main reason I started (and wrote my own
> "thread" class that does the pooling automatically) is so that
> the code I had would work. Some of the earlier JDKs had a problem
> with leaking memory for each thread created. (Even after all of the
> gc() and finalization tricks possible were tried.) This bug has
> been fixed in the Sun JDK but some other JVMs do not yet have
> this fixed.
>
> >Is a 0.15 ms reduction really worth the effort? A server would
> >have to have a very large amount of hits/second before
> >0.15 ms makes any difference.
>
> Depends on how you look at it. Most web servers would love to get
> that reduction on disk performance. Most web servers are *not* CPU
> limited but I/O limited.
Yes, the number of threads started can not be compared to disk access.
In my experience, the servers can indeed be CPU limited when Java is
involved though.
> Now, however, that 0.15ms is on a Linux system running the current
> and reasonably fixed JDK> It is running "greenthreads" which means
> that the threads are *very* light weight and implemented at the
> JVM. On systems with native threads, the thread overhead may well
> be much higher. On my Windows95 box (something no sane person would
> use as a server) the thread overhead is such that I saved over 7ms
> in thread startup time by using an already existing thread from the
> pool. That is a rather large number. On NT, that number was down to
> 4.5 ms (but the standard deviation was *much* higher, meaning rather
> wide ranging results.)
I just tried my test program using the native threads implementation
on Linux available from OpenGroup. The result is indeed in favor of
pooling - the gain is now around 0.6 ms. Still, this is not enough to
convince me. (The results on Windows machines are of no interest to me
since I consider myself sane.) It would be interesting to hear some
overhead figures on Solaris or some other server OS with native thread
support.
/Per Widerlund
