POP QUIZ: How to Troubleshoot a Hang

For this quiz. Let’s say that you run a web server and your customers complain that the site is running slow. What do you do to troubleshoot it?

As a follow-up, if you figure out that one page is the problem, what do you do to look into what is causing that page to be slow?

I’ll accept answers that can be done on the production server or on a test server, but please let me know which one you would do your suggestion on.

As usual, I’ll post the comments and my answer tomorrow or the next day.

Published 07 May 08 09:31 by Tom

Filed under: ASP.NET, Debugging, IIS, Trivia of the Day, Hang

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# ASP.NET Debugging : POP QUIZ: How to Troubleshoot a Hang said on May 7, 2008 2:11 PM:

PingBack from http://blogs.msdn.com/tom/archive/2008/05/07/pop-quiz-how-to-troubleshoot-a-hang.aspx

# David Ayiku said on May 7, 2008 8:22 PM:

I would suggest an admin first look at the server processes to make sure there are no applications hanging on the server. A second option would be to update the statistics/Analyze the database tables in the database. A third option would be to isolate any user transactions during this slow down, gather extensive logging information and analyze it.

Thanks,

Dave Ayiku.

# Aly Boghani said on May 7, 2008 11:39 PM:

I would check following things:

Database Server

- Check Activity Monitor to see any thread that has been there for a while

- check processes in task manager

- inspect sql logs

IIS

- Check worker process size and optimize pool settings

- IIS logs

- Bandwidth test

- Run trace on asp.net pages

# Frank said on May 8, 2008 4:31 AM:

You're funny. Test server. As if anyone has such a thing!

In an ideal world, you'd compare the historical average time-taken with the current average time-taken, then select distinct urls with horrendous time-taken.

Time-taken isn't logged by default, despite it being the most useful log field after http-status and cs-uri-stem!

From there, you know which pages are slow. What do you do next?

# Ray said on May 8, 2008 5:43 AM:

You need to Check how big the page is, exp The Viewstate might make your page big..

# asp99 said on May 8, 2008 8:37 AM:

If a specific page is a problem in that case it is likely that the resources used by that page should be verified. Also the page should be restested by the developer for figuring any ilogical recurrences and logical error if any, database responses and the like.

# K said on May 8, 2008 9:11 AM:

Check the Event Viewer for any errors logged.

Issues might inlcude ->

Large objects written into session, which sometimes lead to worker process unable to process requests.(and may have to shut down and restart. )

Too much ViewState to serialize and send across network.

Db issues.

# Hetal said on May 8, 2008 10:00 AM:

Firstly, it is important to ensure that your environments across different servers are the same.

For our application, we have 4 identical environments setup:

1. Dev

2. QA

3. Stage

4. Production

Typically, I first try to reproduce the issue on the dev. environment. That obviously gives you more control with debugging.

However, having said that, if the problem cannot be replicated on dev, we have extensive logging capabilities for our application. We use NLog for our logging purposes.

Logging is configured so that for different log levels,, it would log different levels of messages into MessageLog, and ExceptionLog tables used for dev. and qa enviornments and MessageCaptureLog and ExceptionCaptureLog for staging/production environments.

In general, the trace level for logging in web.config file on dev. and qa.. is configured to be only Info. This can be varied depending on the amount of information you want to capture.

To troubleshoot on staging or production, we turn the tracing level higher, to all, which allows us to capture complete method trace into tracing tables. (Our design again has seperate tables for capturing messages and exceptions on stage and production. These are MessageCaptureLog and ExceptionCaptureLog)

This logging mechanism is very powerful because it emulates .NET debugging. Are application has not gone live yet, but on dev. and qa. servers, it has truly helped us troubleshoot and trace some wierd behaviors.

# zaza said on May 8, 2008 3:49 PM:

Hi, I have some similar problems, I had to develop an ASP.NET application connecting to an Oracle database 10g and to make everything work together, but it doesn't work I have to solve several problems with the database's sessions.

this is an asp.net application running under IIS, this is executed by many users through internet, the users connect to the database through the asp.net aplication and do any transaction and close the session.

Anytime i see the oracle's sessions through SQL Plus, and there are many session inactive, with the process w3wp.exe and it is growing and growing

What can I do to the sessions disappear from database?

# Tom said on May 8, 2008 4:13 PM:

Zaza,

Sounds like you may want to make sure that the connection objects are getting cleaned up. It is possible that Dispose/Close isn't getting called on them. Eventually it should when they are finalized, but that will cause them to stick around for a long time.

Take a look at http://blogs.msdn.com/tom/archive/2008/04/28/asp-net-tips-looking-at-the-finalization-queue.aspx

for more information on how to see if these objects are in the finalization queue.