tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Saegesser" <>
Subject RE: Anyone know why the ISAPI redirector works how it does?
Date Sun, 24 Jun 2001 13:06:46 GMT
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.

Marc Saegesser

> -----Original Message-----
> From: Andy Armstrong []
> Sent: Sunday, June 24, 2001 7:11 AM
> To:
> 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] \
> 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

View raw message