Marc Saegesser wrote:
>
> Again, threads don't improve performance, in fact they degrade performance
> and on some platforms (namely, Windows) they can degrade performance very
> quickly. Context switching between threads on Win32 is *really, really*
> expensive (several hundred instructions in kernel space). Without
> processors to back up the threads you can just end up wasting cycles
> switching between threads and not accomplishing real work.
Yes, understood. What surprised me was that it wouldn't dynamically
throw new threads in the pool in the specific case where lots of threads
where blocked which is what I assume happens quite a lot in a typical
webserver <--> Tomcat interaction. Extra threads are only compute
intensive when they get scheduled -- if most of them are sleeping then
they're relatively cheap. Of course it turns out, as I read more, than
IIS /can/ dynamically throw new threads in the pool in that eventuality.
I think the only way to bottom this out is for me to write some code to
test it, but I do understand that more threads != more speed in the
general case.
I'm still unconvinced though that the current filter + extension
connector architecture is likely to be any better than a filter only
implementation on the basis of what I've read about the internals of
IIS.
Time to stop talking and start experimenting I think ;-)
--
Andy Armstrong, Tagish
