views:

33

answers:

1

We have an Asp.Net 2.0 web app that is running on IIS (I've tried 5.1 on XP and 6.0 on 2003 with same results) and it works briefly and then becomes non-responsive. The odd thing is that requests from the local server (using "localhost" or the ip) continue to work fine. But all page requests from other machines just time out. I don't see any indication that those requests are ever getting to Asp.Net at all.

I'm sure that the app is using more background threads than it really should need via the ThreadPool, roughly on the order of about 40. Howevever, I'd like to understand the problem a little better before I go about fixing it. I've tried increasing the limit using the SetMaxThreads method with no success. GetMaxThreads indicates that there are plenty of available threads as well.

Any ideas what I should be looking for? Is this an IIS or Asp.Net issue? Thanks!

+1  A: 

I've had this happen before in one of my applications. I used PerfMon to localize what was going on with the box (using the ASP.NET and ASP.NET Apps performance objects). In my particular case, it told me that the requests were going to the .NET DLL and it was a code issue. It was a fairly easy fix after that was identified, but YMMV.

I think you need more information, and would use PerfMon to get it.

bryanjonker
How did you track down the request processing with perfmon? I'm familiar with following counters (threads, memory usage, etc), but not that level of tracing.
Eric Nicholson
If you add a counter (see http://support.microsoft.com/kb/305610 to add counters), you'll get a drop-down list of performance objects. Two of the performance objects are ASP.NET and ASP.NET Apps. The "Apps" has requests served, etc., and the regular ASP.NET state server sessions and worker processes. You can also access the CLR objects directly through PerfMon.
bryanjonker
I can definitely see that the request is "queued" by Asp.Net, but it doesn't seem like it's ever processed.
Eric Nicholson