Debugging hanging website

We have a problem with an asp.net website we part build and host for a client. About a week ago the website would just failed to respond to requests, no error was returned. No code was deployed by us but the client does upload non compiled pages from time to time.

Restarting the app pool the site runs on fixes the problem but in 1-8 hours the same will happen again.

The strange thing is that the iis log shows that, while the site appears to not be responding, pages appear to be served as normal, almost as if requests are stuck in a queue or something.

The event log of the server shows nothing out of the ordinary either. The site is run on 2 servers which are load balanced using NLB. Switching the load onto one server then another shows the same results indicating that the issue is not environment specific but an issue with the application itself.

We have run DebugDiag with no obvious results too. We are not sure where to go with getting to the bottom of this now. Can anyone suggest some debugging techniques we could use to eliminate anything or discover the source of the issue?

Sorry I forgot to add cpu usage and memory are relatively normal. Also our servers host multiple websites too.

Sheff 2010-05-18 10:13:52

And yes its reading from a sql database. If there was a deadlock issue would the server not return a 500 with a sql exception? I will run a sql trace however to determine if there are issues.

Sheff 2010-05-18 10:14:48

Yes there is no response stream whatsoever. the browser just sits there and simply waits for a response. Hmmm some of the clients pages they add are classic asp. What do you mean by terminating static variables? Do you mean a variable that last the lifetime of the app. If so would we not see abnormal memory usage?

Sheff 2010-05-18 10:28:45

"If so would we not see abnormal memory usage?" that's what I'd thought too.. but that wasn't the case in our app, CPU and mem-usage was pretty normal. By terminating I ment: refactoring static variables to session variables or public singletons for the session (depending on the use).

riffnl 2010-05-18 10:41:37

Ok thanks I will check our clients code for such issues.

Sheff 2010-05-18 11:18:36

You're using SQL Server I see. Are you closing each connection after you've used it?

riffnl 2010-05-18 11:22:42

Like I say, "we" haven't changed any code. our client could have though. Even so if connections weren't closed a sql exception would be returned with a connection pool error I would have thought?

Sheff 2010-05-18 11:24:57

I think so, but I know we kept the (bad-practise) SqlConnection static too (one of the main problems we ran into). We've never seen a error screen back then - just white pages.. (was hell)Besides that, we never had any problems during slow hours.

riffnl 2010-05-18 12:11:52

ansaurus

tags:

views:

answers:

Debugging hanging website

related questions