ansaurus

Question

Answer 1

+2 A:

There are a lot of reasons this could happen. The first thing I usually look for is a network delay of some kind. Even if your ASPX page is nothing but the two-line snippet you posted, several things may happen earlier in the pipeline:

Security rules (it might be trying to contact an authentication/authorization service or database somewhere);
Custom HttpModules, configured through the web.config or directly through IIS;
Various other settings in web.config could trigger early actions (i.e. tracing/logging, maybe the log is full or pointing at a network location)
Any code that executes in global.asax
Loading the ASP.NET identity's user profile (if this option is configured, by default it is not)
And so on...

Some would only happen when the app is first loaded, others would occur on every page load.

Non-responsive web apps with low CPU and disk usage could also indicate that all of the available threads in the ThreadPool are blocked, either due to a deadlock (careless use of the ThreadPool within the app itself, perhaps), or waiting on an external resource. Even if your test page doesn't call up any external resources, if you have 50 users online all calling up pages that do, it can easily starve the pool if the site is poorly designed (see below). If it took exactly 30 or 60 seconds to load the page then it could be a red flag indicating a timeout somewhere.

One common design mistake in ASP.NET websites is synchronous data access, I/O, or network code (i.e. invoking a remote web service) on a frequently-used page or code path. These are all blocking calls by default, and if the pages are not converted to the Async model, threads won't be released back to the ThreadPool while the app waits for a response, preventing the server from accepting any new connections after the pool is used up (I think it's 25 threads by default). On a low-traffic site, this might never be an issue, but on a high-traffic site it becomes an issue very fast.

Of course I'm really just throwing out possibilities here. Without knowing a lot more about the site and the configuration, it's hard to say for sure. Running detailed traces (especially on server-initiated network connections and file access) would likely tell you more.

Aaronaught 2009-12-12 06:27:20

Hey, I realize it'll likely be speculation without way more information. I think you've hit the nail on the head with filling the app pool's worker thread limit. I did notice some very inefficient methods used to render the page, I just couldn't see how they'd effect requests to an unrelated page. The original developer does seem to have taken knowing that it'd be served off a CDN as a license to not bother putting any caching in his own code meaning every page load of the homepage actually does a good 4-5 web service calls so it could've easily used up that limit with the CDN misconfigured.

Tim Schneider 2009-12-12 10:18:21

ansaurus

tags:

views:

answers:

Unresponsive ASP.NET site in IIS7

related questions