On this page:

Related pages:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
16 rates

You can learn that your application's response time is slow in the following ways:

  • You receive an alert: If you have received an email alert from AppDynamics that was configured through the use of health rules and policies, the email message provides a number of details about the problem that triggered the alert. See information about Email Notifications in Notification Actions. If the problem is related to slow response time, see Initial Troubleshooting Steps.
  • You view the Application Dashboard for a business application and see slow response times.
  • A user reported slow response time that relates to a particular business transaction, for example, an internal tester reports "Searching for a hotel is slow". 

Initial Troubleshooting Steps

In some cases, the source of your problem might be easily diagnosed by choosing Troubleshoot > Slow Response Times in the left navigation pane. See Slow Response Times.

.NET Resource Troubleshooting

If you've tried to diagnose the problem using those techniques and haven't found the problem, use the following troubleshooting approaches to find other ways to determine the root cause of the issue.

Step 1 - CPU saturated?

Is the CPU of the CLR saturated?

 How do I know?

  1. Display the Tier Flow Map.
  2. Click the Nodes tab, and then click the Hardware tab.
  3. Sort by CPU % (current).

If the CPU % is 90 or higher, the answer to the question in Step 4 is Yes. Otherwise, the answer is No.

Yes – Go to Step 2

No – Review various metrics in the Metric Browser to pinpoint the problem.

In the left navigation pane, click Servers > Tiers & Nodes > slow tier. Review these metrics in particular:

  • ASP.NET -> Application Restarts
  • ASP.NET -> Request Wait Time
  • ASP.NET -> Requests Queued
  • CLR -> Locks and Threads -> Current Logical Threads
  • CLR -> Locks and Threads -> Current Physical Threads
  • IIS -> Number of working processes
  • IIS -> Application pools -> <Business application name> -> CPU%
  • IIS -> Application pools -> <Business application name> -> Number of working processes
  • IIS -> Application pools -> <Business application name> -> Working Set

You have isolated the problem and don't need to continue with the rest of the steps below.

Step 2 - Significant garbage collection activity?

 How do I know?

  1. Display the Tier Flow Map.
  2. Click the Nodes tab, and then click the Memory tab.
  3. Sort by Time Spent on Collections (%) to see what percentage of processing time is being taken up with garbage collection activity.

If Time Spent on Collections (%) is higher than acceptable (say, over 40%), the answer to the question in Step 5 is Yes. Otherwise, the answer is No.

Is there significant garbage collection activity?

Yes – Go to Step 3.

No – Use your standard tools to produce memory dumps; review these to locate the source of the problem.

You have isolated the problem and don't need to continue with the rest of the steps below.

Step 3 - Memory leak?

Is there a memory leak?

 How do I know?

  1. From the list of nodes displayed in the previous step (when you were checking for garbage collecting activity), double-click a node that is experiencing significant GC activity.
  2. Click the Memory tab, then review the committed bytes counter and the size of the Gen0, Gen1, Gen2 and large heaps.

If memory is not being released (one or more of the above indicators is trending upward), the answer to the question in Step 6 is Yes. Otherwise, the answer is No.

Yes – Use your standard tools for troubleshooting memory problems. You can also review ASP.NET metrics; click Tiers & Nodes > slow tier > ASP.NET.

No – Use your standard tools to produce memory dumps; review these to locate the source of the problem.

Whether you answered Yes or No, you have isolated the problem.