Hi, I'm a new, late starter on this thread...
My understanding is that IIS runs about 15 threads and for filters it runs it on one
of the threads, and for extension procs it uses the model defined in the application
setup of the virtual directory (Low [iis thread], Medium [pool thread], High
[isolated, app specific threads]). From what I can see of the Tomcat code, because it
has the Filter and Extension call backs in the same DLL it will always default to Low
(ie. as a filter).
My understanding is that the best way to do the IIS/Tomcat integration is tricky - but
worth it.
You would:
o Have a separate filter to do the absolute minimum to check whether the URI is for a
Servlet - this would run on the IIS thread and then direct it to the Exension Proc.
o Have a separate DLL implementing the extension proc and have it run in the High
protection model.
o In the extension proc you would implement the asynch call back model where in simple
terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own pool of
threads to process the request by releasing the IIS thread and holding a ref to a
callback sig function so that when Tomcat has finished it sigs back to IIS that it is
complete and IIS then takes over again. This is the way ASP works and makes sure you
never get the dreaded "Server Busy" response back to the client because the scarce IIS
threads are exhausted.
Apart from that, I haven't thought about it ;-)
I'm happy to help...
Cheers...Pete
-----Original Message-----
From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
Sent: Sunday,24 June 2001 11:17
To: [EMAIL PROTECTED]
Subject: Re: Anyone know why the ISAPI redirector works how it does?
Marc Saegesser wrote:
>
> I don't have any problem with the experiment, and couldn't stop the
> *experiment* even if I wanted to. By all means, scratch the itch.
>
> I am curious though, what it takes to cause the thread starvation in a
> normal environment (what ever that is). Adding the complexity of a thread
> pool will slow down processing by some amount in the non-starved case. For
> the case where thread starvation is occurring, it stands to reason that we
> have *lots* of requests and lots more requests and threads than processors
> to throwing more threads probably won't improve the throughput for Tomcat
> requests. It might improve the throughput for the static pages served by
> IIS directly since those requests won't be stuck behind potentially long
> running servlet requests, but then only if those long running threads are
> blocked on I/O. Basically, throwing threads at a problem usually doesn't do
> much for performance.
>
> Still, I'd be interested to see how this experiment effects performance.
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.
>
> Marc Saegesser
>
> > -----Original Message-----
> > From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, June 24, 2001 7:11 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Anyone know why the ISAPI redirector works how it does?
> >
> >
> > 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
--
Andy Armstrong, Tagish
------------------------------------------------------------------------------
This message and any attachment is confidential and may be privileged or otherwise
protected from disclosure. If you have received it by mistake please let us know by
reply and then delete it from your system; you should not copy the message or disclose
its contents to anyone.
