AppDynamics Application Intelligence Platform

3.9.x Documentation

PDFs

Learn by Watching

Doc Maps

This topic describes call graphs for code-level diagnostics.

Call Graphs

A call graph lists the methods in a call stack and provides information about each call. Call graphs help you diagnose performance issues and optimize the flow of a complex business transaction.

AppDynamics call graphs provide the following information:

  • Call information: This includes the total execution time, the node name for the call graph, and the time stamp for the start of execution.
  • Method execution sequence: An easily readable method execution sequence with the class names and the method names of each method.
    • Application component information: Application component information such as Servlet names, Struts Action classes, EJB names, Spring Bean IDs and proxies, message listeners, etc. POJOs are represented by class name, unless the POJO is a special type of component such as a struts action invoker. The class name is available for all call graph elements including those having logical class names.
    • Code line number: The line number of the element in the source code, if available.
  • Time distribution for each method: The time distribution for each method along with the percentage of the total time in the call graph.
  • Exit call information: Links to more information about exit calls such as  JDBC, JMS, and Web Services.
  • Application component summary information: Summary information for each element in the call graph.

In addition you can:

  • Filter the call graph list using criteria such as application components, time, or all or part of the name.
  • Select an element of the list and set it as the root of the list to drill down into large call graphs more efficiently.
  • Export the call graph to PDF to share the information with other team members.

(warning) There are two kinds of call graphs: full and partial.  Full call graphs capture the entire call sequence and are captured periodically for general monitoring purposes.  Partial call graphs capture the call sequence from the point at which the call sequence has been determined to be slow or have errors, and thus may not include the initial steps in the sequence. Because they are not complete, all the calls that you are expecting to see for a transaction, such as exit calls, may not be displayed in a partial call graph.

Aggressive Slow Snapshot Collection - Java Only

By configuring call graphs to collect slow threshold transaction collections, you can ensure that fewer partial call graphs will be captured. For more information, see Enable / Disable Aggressive Slow Snapshot Collection.

To view call graphs

1. From a dashboard, click the Transaction Snapshots tab.   

2. Do one of the following:

  • Click All Snapshots to see all snapshots.
  • Click Slow and Error Transactions to see snapshots for slow and error transactions.
  • Click Periodic Collection to see snapshots collected periodically.

2. Select a particular transaction snapshot and click View Transaction Snapshot.

3. Click the Drill Down icon to see the call graph for the snapshot.
By default the originating call graph in a business transaction,  generated by the entry point on the entry point tier, displays.

To Filter and Search for a Class Name in a Call Graph

The call graph is displayed when you click on the drill down option on the  snapshot. You can filter and search for a particular class name on the call graph. To do this, use the search box available on the left side of the call graph.

Diagnosing the Root Cause of Problems Using Call Graphs

Troubleshoot Problems using Call Graphs

You can use call graphs to troubleshoot the problems in the flow map. Drill down into each tier using the Drill Down option. If there is only one invocation, AppDynamics displays the call graph.

When there are multiple invocations for that tier which participated in the transaction, the Action -> Drill Down menu displays a list of all call graphs for the node. Each call graph represents a call into the node. For example, if JVM A makes two remote calls to JVM B, then JVM B will have two call graphs.

Understanding Data Captured in Call Graphs

Class/Method Names and Time spent

Call graphs represent the sequence of execution of code on the application server. Each row represents a method call and the tree represents the execution sequence.

The total time spent in the call graph is displayed on the top left corner of the call graph.

The Time (ms) column in the call graph shows the time spent in each method.

External Calls Invoked by a Method

If a method invokes external calls outside of the app server, such as a JDBC query or a Web Service call, there is a link to the call in the call graph, if the exit call lasted longer than the threshold. For example, JDBC/ADO.NET call taking more time than the specified time (in milliseconds), which defaults to 10ms, is captured in the call graph. See min-duration-for-jdbc-call-in-ms in App Agent Node Properties Reference.

The following example shows the details of a JDBC call that include the query, the execution time of the query, the number of times that the application code iterated over the query results (ResultSet Count) and the time in milliseconds that the application code spent iterating over the results (ResultSet Time).

If the detail screen has a Drill Down link, you can get a call graph for the calls downstream from the original call.

Viewing Call Graph Hot Spots

The most expensive methods are listed in the Hot Spots section of the transaction snapshot.

Advanced Options

Classes displayed in the call graphs

The sequence of Java method invocations in a call graph can include hundreds of classes. These classes are categorized as:

  • Application classes
  • AppServer/Container/Middleware classes (For example: Tomcat runtime classes, Websphere runtime classes, etc.)
  • JDBC Driver/External infrastructure library classes (For example: Oracle Driver classes, Axis Web Service runtime classes, Hibernate classes, etc.)
  • Third party utility libraries (For example: Apache commons libraries)
  • Java/J2EE core libraries

Adding all of these classes together in a call graph is counterproductive for troubleshooting. The only mandatory classes required, are the classes from first category- the Application classes. You might require the other classes only in certain situations. To make the call graph more readable and to avoid the overhead of processing the timing information for all the non-application classes, other classes are not shown in the call graph.

Packages and Namespaces excluded from the call graph

A call graph can have a list of packages (Java) or namespaces (.NET) that are not displayed. To access this list, click on the message for "Some packages/namespaces have been excluded from the Call graph" message.

The PHP and Node.js agents do not support call graph exclusion.

Configure instrumentation

You can right-click on any item in a call graph and select Configure Instrumentation for this Class/Method.

The Configure Instrumentation window presents a drop-down menu form which you can select the type of configuration that you want to create for the method.


This short interactive video traces the typical steps of identifying the cause of communication issues between tiers in your application.

Learn More