Unresponsive ASP.NET site in IIS7
Where I work we recently had a site which was incredibly unresponsive (1 minute or more for a simple request. When I tested it I tried a page as simple as:
<%@ Page Language="C# %>
<html><body><h1>Hello World</h1></body></html>
(PS: Lack of code-behind declaration is intentio开发者_开发知识库nal - that's all it was. No actual code)
And it still took as much as a minute to respond. A static .html file from the same IIS site was instantaneous though.
The site was getting quite a lot of hits, the CDN we were using was actually misconfigured so it was getting a TON of hits. Once we fixed that config it went back to normal speeds, but it still bugs me because I couldn't work out what was going wrong and as far as I can tell there's no reason the server shouldn't have been able to cope with it.
The server's CPU load was cruising at like 5%, it had over a gig of RAM unused and all the other sites on the server were loading fine and the staging site (Which had all the same external dependencies) was loading fine.
Anyone have any idea of what kind of things could cause this? Is there any resource within a single site (Or app pool - it has it's own) that we could use so many of that entire site goes slow? I didn't write it myself so I'm not confident that objects that are used are appropriately disposed, there could easily be undisposed web requests, file or database connections, but I couldn't see how any of those would slow down the tiny test page I made...
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.
加载中,请稍侯......
精彩评论