OK, I've done a bit more digging. From what I've read about ISAPI it
seems that thread exhaustion can be a problem both for filters /and/
extensions[1]. The advice on this page /is/ to avoid filters, but I
assume that's just because filters will be invoked for every request --
unfortunately that's unavoidable for the Tomcat connector because we
need to see every request in case Tomcat can handle it.

So, currently we have a filter that delegates to an extension, both in
the same DLL. If extensions execute in a different thread pool from
filters it's possible that this helps performance, but it's not clear
from the MS documentation that this is the case. What MS do specifically
say is that, in cases where a filter or extension may block for any
length of time the blocking part should run in a seperate thread so that
IIS doesn't get thread starved -- this makes sense, and suggests that
the correct performance oriented architecture for the IIS connector
should be a filter (with an optimized 'straight throw' path) which
delegates Tomcat requests not to an ISAPI extension but to a worker
thread taken from a pool that is internal to the connector.

This is more complex than what I had in mind, but I'm prepared to give
it a try. Before I do, does anyone have any empirical evidence about
what works best with IIS? 

[1] http://msdn.microsoft.com/library/default.asp? \    
url=/library/en-us/iisref/html/psdk/asp/perf4vsj.asp

"Ignacio J. Ortega" wrote:
> 
> > So, +1 for trying a different approach without breaking what's already
> > there?
> 
> My swahili is at times hard to understand :))
> 
> Yes i'm +1 on trying what you are proposing in another place on jtc tree
> and leaving iis as it is now.. I'm really courious about what you find
> .. every bit of performance is welcomed ever .. so if there is a bit
> waiting for tomcat lets catch it ..:))
> 
> i recall that i'd found the same architecture in other ISAPI modules
> like resin...
> 
> Saludos ,
> Ignacio J. Ortega
> 
> >
> > --
> > Andy Armstrong, Tagish
> >

-- 
Andy Armstrong, Tagish

Reply via email to