(sorry to follow myself up, but I've just found some more evidence about
this)
Andy Armstrong wrote:
[snip]
>
> Yeah, well I'm not entirely convinced myself. I'm guessing, from what
> I've read on the MS site, that IIS actually runs with quite a small,
> fixed size, pool of threads and relies on its ability to serve static
> content very quickly to ensure that this is adequate. As soon as you
> start executing (relatively) slow requests in threads from this pool you
> end up with most of the threads blocked. That's my reading anyway -- I
> might do some experiments to find out how many distinct threads IIS is
> using before I do anything else.
>
> I am prepared to believe that if IIS is tightly optimized for static
> content and runs with a thread pool that is only just large enough for
> its normal needs that this might be the case, though, like you, I'm a
> little sceptical.
Hmm. Well, surprisingly, according to this page[1] the default thread
pool size for IIS is 10 times the number of processors and the server
doesn't do anything adaptive with this number though it can be changed
in the registry. This number does seem surprisingly low -- I can see
how, in cases where the server was handling a lot of traffic of which
some was being delegated to Tomcat there could be starvation.
[1] http://www.google.com/search?q=cache:2jnr72XWvVU: \
msdn.microsoft.com/componentresources/html/articles \
/ta/ta_030.asp+iis+thread+pool+size&hl=en
--
Andy Armstrong, Tagish
