Beginning in February 2020, AppDynamics switched from Semantic Versioning to Calendar Versioning for some agents and the first deployments of SaaS Controllers. In March 2020, the entire product suite will use Calendar Versioning.


Skip to end of metadata
Go to start of metadata

Related Pages:

Your Rating:
Results:
1 Star2 Star3 Star4 Star5 Star
21 rates

You may receive a notification based on a health rule violation, see performance indicators in flow maps or transaction scorecards that indicate slow response times. When you do, the following guidelines provide a strategy for troubleshooting and diagnosis.

The Slow Response Times Dashboard in the Troubleshoot menu lists the Business Transactions most responsible for slow Average Response Time (ART). From that dashboard, you can select a time range centered around a spike in ART that also captures more normal-looking time spans. This information is also available through the Top Business Transactions tab on the By Contribution to App Average Response Time tile.

Step 1: Check for slow or stalled business transactions. 

AppDynamics uses transaction thresholds to detect slow, very slow, and stalled transactions. Follow these steps to determine if you complete Step 2 or move on to Step 3. 

Do you have slow or stalled transactions?

  1. Make sure that the time frame selected in the Controller UI encompasses the time when the performance issue occurred. If it's a continuing condition, you can keep the time frame relatively brief. Use the Time Range drop-down menu.
  2. Click Troubleshoot > Slow Response Times.
  3. Click the Slow Transactions tab if it is not already selected.
  4. Do you see one or more slow transaction snapshots on this page? Yes or No?
    • If Yes – Go to Step 2 to drill down to find the root cause.
    • If No – Go to Step 3 and check for slow backends.

Step 2: Drill into slow or stalled transactions to determine the root cause.

  1. From the left menu, navigate to Troubleshoot > Slow Response Times.

  2. In the lower pane of the Slow Transactions tab, click the Exe Time (ms)column to sort the transactions from slowest to fastest.

  3. Select a snapshot from the list and click Details
  4. Review the Potential Issues list to see the longest-running method and SQL calls in the transaction. 
  5. Click a potential issue and select Drill Down into Call Graph to go directly to that point in the call graph, or click Drill Down in the transaction flow map pane to see the complete set of call graph segments retained for this transaction.
  6. View the Time (ms) column to see how long this method execution takes relative to the transaction execution time. 
  7. Click the HTTP link in the last column on the right to display the information details pain. In this example, the selected method is taking 96.3% of the transaction execution time. 
  8. Note the Class, Method, and Line Number (if available) represented by the execution segment. This information provides a starting point for troubleshooting this code issue. 

If there are multiple slow or stalled transactions, repeat this step until you have resolved them all and then continue to Step 3.

Step 3: Check for slow database or remote service calls on the backend.

AppDynamics collects metrics about the performance of business transaction calls to the databases and remote servers from the instrumented app servers. You can drill down to the root cause of slow database and remote service calls.

  1. Click Troubleshoot > Slow Response Times, then click the Slowest DB & Remote Service Calls tab.
  2. Select a call from the list and click the View Snapshots link to show a list of Correlated Snapshots.
  3. Click the Exe Time (ms)column to sort the transactions from slowest to fastest.
  4. Select a transaction and click Drill Down
  5. Select a potential issue from the Potential Issues list 
  6. Click Drill Down into Call Graph to go directly to that point in the call graph, or click Drill Down in the flow map pane to see the complete set of call graph segments retained for this transaction.
  7. Review the Time (ms) column and select the transaction with the longest execution time for this method relative to the transaction execution time. 
  8. Select the DB & Remote Service Calls tab.
  9. Do you see one or more slow calls on the SQL Calls or Remote Service Calls tabs? Yes or No?
    • If Yes – Go to Step 4 to drill down and find the root cause.
    • If No – Go to Step 5 to determine if the problem is affecting all nodes in the slow tier.

Step 4: Drill into SQL or Remote Service Calls to determine the root cause.

  1. On the SQL Calls tab of the transaction snapshot, sort the SQL Calls by Avg. Tims(ms). 
    1. Slow database call– click the database call to gain information about the call.
    2. If you have Correlated snapshots between Java applications and Oracle databases – drill down into the Oracle database on the Transaction Snapshot to view database details captured during the snapshot.
    3. If you have AppDynamics for Databases – right-click the database on the Application, Tier, Node or Backend Flow Map, and choose Link to AppDynamics for Databases. You can use AppDynamics for Databases to diagnose database issues.

    4. If you have Database Monitoring  right-click the database on the Application, Tier, Node or Backend Flow Map, and choose View to delve into database problems.



  2. On the Remote Service Calls tab, sort the queries by Avg. Times(ms).
  3. Select the slow call. 
  4. Click Drill Down into Downstream Call to gain further insight into the methods of the service call. 
  5. Sort the methods by the Time (ms) column.
  6. Select a slow method. 
  7. Click Details.

Step 5: Does the problem affect all nodes in the slow tier.

  1. In the Application or Tier Flow Map, click the tier or node icon to see a quick overview of the health of each node in the tier.
  2. Is the problem affecting all nodes in the slow tier? If all the nodes are yellow or red, the answer to this question is Yes. Otherwise, the answer is No.
    • If Yes – Go to Step 6.
    • If No – The problem is either in the node's hardware or in the way the software is configured on the node. If only one node in a tier is affected, the problem is probably not related to the application code. Follow the steps below to determine a hardware related problem.
      1. In the left navigation pane, click Tiers & Nodes
      2. Expand the Tier in the right pane and double-click the affected node to open its Node Dashboard.
      3. Click the Memory tab
        1. Explore each of the available tabs to determine if you need to add memory to the node, configure additional memory for the application, or take some other corrective action. 
      4. Click the Server tab. 
        1. If the Hardware tab indicates a hardware related problem, contact your IT department.

You have isolated the problem.

Step 6: Check to see whether the problem affects most business transactions

  1. On the Application Dashboard, look at the Business Transaction Health pane on the right side of the screen.
  2. Is the bar representing Business Transaction Health is primarily yellow or red? Yes or No?
    • If No – The 
      1. Click Business Transactions in the left navigation pane.
      2. Sort by Health, Transaction Score or other column headings to find the business transaction that is experiencing issues.
      3. Double-click the problematic business transaction to see its dashboard, then use the tabs to diagnose the problem. 

You have isolated the problem. 

Need More Help?

If you've tried to diagnose the problem using the previous steps and haven't found the problem, see additional information for your specific agent:


  • No labels