This page applies to an earlier version of the AppDynamics App IQ Platform.
For documentation on the latest version, see the 4.4 Documentation.


On this page:

Related pages:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
61 rates

A call graph in a transaction snapshot shows you business transaction processing information on a particular tier that participated on the business transaction. A call graph lists the methods in a call stack and provides information about each call. 

A call graph can tell you general information such as the total execution time, the node name, the time stamp for the start of execution, and the unique identifier for the business transaction instance. Call graphs help you diagnose performance issues and optimize the flow of a complex business transaction.

Call graphs are also captured by the Node.js agent in process snapshots, which describe an instance of a CPU process on an instrumented Node.js node. See View Process Snapshots.

Full, Partial and Hot Spot Call Graphs

A call graph can be one of three types:

  • Full call graphs capture the entire call sequence for the business transaction invocation. In this case, call graphs exist for each monitored node involved in the processing of the business transaction. Periodically collected and diagnostic snapshots are always full call graphs. 
  • Partial call graphs represent the subset of the call sequence for processing a business transaction, typically from the point at which the transaction has been determined to be slow or have errors. Partial call graphs are identified as such in the transaction snapshot.
  • For Java monitoring, AppDynamics collects hot spot call graphs. Like partial call graphs, hot spot call graphs are retained because a transaction is recognized to be slow, stalled or an error transaction. Unlike partial call graphs, however, a hot spot call graph includes call segments generated before the transaction exceeded a user experience issue threshold. The segments are those that AppDynamics has recognized as potential issues based on analysis of performance patterns for the transaction. (For more information, see information on aggressive slow snapshot collection in Configure Call Graphs). 

    Hot spot call graphs are labeled as such in the call graph drill down window.

    Note that hot spot call graphs are distinct from the hot spots that appear in the snapshot view. For information on hot spots in the snapshot, see Transaction Snapshots.  

Viewing Call Graphs

To view a call graph:

  1. Open the dashboard for the business transaction for which you want to see a call graph and click the Transaction Snapshots tab.
  2. In the transaction snapshot list, double click on a snapshot. 
  3. Click the Drill Down link for the tier on which you want to see a call graph. An asterisk next to the link means that multiple calls were made at this tier for the transaction, which a dialog offers as choices to drill down into.   

In the window, the method execution sequence shows the names of the classes and methods that participated in processing the business transaction on this node, in the order in which the flow of control proceeded. 

For each method, you can see the time spent processing and the line number in source code, enabling you to pinpoint the location in code that could be affecting the performance of the transaction. 

The call graph window includes UI controls for navigating large call graphs. For instance, you can use the filter field to have only particular method or types of methods displayed. When you find a method of interest, you can set it as the root method in the tree to view only the portion of the call graph that occurs from that point forward.


External Call Information in Call Graphs

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.

JDBC and JDBC ResultSet Iteration in Call Graphs

A database call in code is usually performed in two phases: first the code creates and executes a SQL query, and second the code iterates through the results. In code, the follow sample illustrates what this might look like:

At runtime, the JDBC client first executes the query. The database returns a pointer to a database buffer with the results of the query, typically passing 10 records at a time. The JDBC client iterates through each batch, retrieving the next 10 records only if the previous 10 did not satisfy the query.  

Since different performance considerations can apply to these two distinct phases, AppDynamics represents them separately in call graphs:

  • For the JDBC execute call, it shows the SQL query and the execute time (accessed by a JDBC link in the External Call column). 
  • For the ResultSet iteration, is shows the count (number of iterations) and the total time (accessed by a JDBC ResultSet Iteration link in the External Call column).
Minimum Capture Threshold Times for SQL Calls

The query and result set iteration are both subject to the minimum capture threshold times for SQL calls, 10 ms by default. If the execution time for a query or result set iteration does not exceed the threshold it does not appear in the call graph.  This means a given database interaction may be represented in a call graph in one of three ways depending on which parts of the operation took longer than 10 ms, if any:

  1. Only the query appears (callout 1 in the image below) 
  2. Only the ResultSet iteration appears (callout 2)
  3. Both appear (callout 3)

Clicking the link takes you to more details for that JDBC call or ResultSet iteration. 

Maximum Number of SQL Queries in Snapshots

The maximum number of SQL queries in snapshots is set to 500 by default, and determined by the node property max-jdbc-calls-per-snapshot. If SQL queries you expect to see are not reported in a callgraph, you may need to increase the number the value for that property. See App Agent Node Properties.

 

Request Root Node

The call graphs in transaction snapshots of the Node.js, PHP, and Python agents have an artificial root node named "{request}" .

For Python and PHP, the purpose of this node is to reconcile time differences between the total business transaction time and the sum of the observed call graph nodes, to act as a single entry point for the call graph, and to contain any exit calls which could not be attributed to any other nodes.

For Node.js, the "{request}" node in a business transaction call graph signals the availability of a process snapshot call graph that intersects with the transaction snapshot. If there is no "{request}" node, no process snapshot is available. For more information, see Process Snapshots and Business Transaction Snapshots.

Node.js Call Graphs

When the Node.js agent captures a complete call graph, the call graph tab of the transaction snapshot displays the total execution total time of the transaction, including wait times, at the top the call graph.

The execution time shown in the call graph pane is the sum of the times of the individual method calls inside the call graph. This value may be less than the total execution time because it does not include wait times between calls.

Displaying Excluded Classes in Call Graphs

The sequence of method invocations in a call graph may involve hundreds of classes. These classes include user application classes, framework classes (such as Tomcat or Websphere runtime classes), Java/J2EE core libraries, .NET Framework classes, and more. 

Not all of those classes may be relevant to the type of troubleshooting you normally do. In most cases, your primary interests are the custom application classes you have built on top of the framework or language platform. Other classes may be needed, but only on rare occasions.

To make the call graph more readable and to avoid the overhead of processing the timing information for non-user-application classes, other classes are not shown in the call graph.

If packages (Java) or namespaces (.NET) have been excluded, you can click the packages/namespaces have been excluded link to view the packages, and optionally configure the classes to be included in call graphs. 

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 from which you can select the type of configuration that you want to create for the method.

  • No labels