We've seen something like this on Win2K with JRun 3.0 SP2, but the
bottleneck appears to be getting output from JRun back to IIS. 

There are some periods in which the IIS logs show 20-40 .jsp pages being
completed in the same second; however, if you subtract the response times
from the IIS log entries, you find that the requests arrrived over a
two-minute period prior. Our application log records a stamp at the start
and end of the JRun page in question, so we are able to see that the
requests did indeed arrive over a two-minute interval, then got flushed out
of JRun and back to IIS all at once. This could be due to database
contention in the body of the pages (unlikely), or it could be some kind of
block writing back to IIS.

The second scenario we have seen is when we know that requests arrived over
a two-minute period, but it seems that either IIS or JRun queued the
requests and then flushed 89 requests through in a six second period.
Because we do not see the application log entry associated with the start of
each page, we know this is not due to database contention in the body of the
page, and rather appears to be some kind of bottleneck from IIS to JRun.

FWIW: in our test lab, we have much better results overall (lower response
times and no long-running JSP pages) with Microsoft's Network Load Balancing
turned OFF. Turning off NLB in our production environment does not have the
same effect, however. This may be due to the many other apps which are
co-hosted on our production servers.

/dmc
============

Joe said:

We currently have JRun v2.3.3 Build 158 running on an
IIS web server. The server is NT 4.0 sp6a.

We have an issue where the JRun ISAPI requests start
to build until the server becomes useless.

Is anyone aware of this issue?

Is there any way to timeout the ISAPI threads after x
number of seconds?

With the out of the box configuration how many threads
does Jrun have for the ISAPI dll?

Can we increase the number of threads JRun is using 
for the ISAPI filter?

Any help on these issues is greatly appreciated
Joe


David M. Chandler
Hosting Analyst
NCS Pearson
319-339-6400 x3944
 <<David M. Chandler (E-mail).vcf>> 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to