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
