To monitor end-to-end transaction performance for an asynchronous transaction, you must identify the demarcator for the transaction's logical endpoint. There are two ways you can define a transaction demarcator:
For Java applications, you can specify a tier on which the end to end transaction processing is completed. This lets you determine the logical transaction response time for transactions that perform asynchronous backend calls (such as JMS calls or web service calls). When the last of the threads spawned by the transaction terminates on that tier, the agent considers the transaction complete.
The Java Agent uses patent-pending heuristics to determine when the last thread associated with the Business Transaction has run. These heuristics are successful for many common cases. In complex environments with many thread handoffs unconstrained by frameworks, these heuristics may be inaccurate. For example Reactive Java, AKKA, or Scala environments.
You should validate that the last thread on tier mechanism returns an end to end time consistent with the end to end latency shown within full transaction snapshots.
- For Java or .NET applications, you can identify the method that acts as the logical endpoint for the transaction processing sequence. For a response handler, this could be a method that watches for spawned threads to complete and when done, assembles the response and sends it back to the client.
You may specify more than one endpoint demarcator for a particular business transaction. In this case, the first match ends the transaction for purposes of end-to-end latency monitoring. Be careful not to configure multiple demarcators that could be satisfied on different tiers for a given transaction.
For the last thread on tier demarcator type, the transaction endpoint is considered to be the time when the thread that receives the traced transaction terminates or the latest points at which any descendant threads terminate.
For the method-based transaction demarcator option, you can configure the demarcator to consider runtime state, such as the values of parameters passed to the method. This allows you to account for an application design in which the completion of a logical business transaction is signaled by the value of a method parameter or return value.
For .NET POCO entry point on methods that return a
Task class, AppDynamics tracks the return of the task object as an end to end latency transaction automatically. You can configure your own transactions as end to end transactions for Java and .NET applications as described here. See POCO Entry Points for information on
Task-based POCO entry points.
To create the configuration:
- Open the Configuration > Instrumentation page and choose Asynchronous Transactions from the top menu. You likely need to expand the menu list (>>) to view the Asynchronous Transactions item.
- Click Add and choose the demarcator method:
- Java only: Transaction is complete when last thread on specified Tier is finished running.
- Java or .NET: Transaction is complete when specified class/method is invoked. However, the end-to-end transaction time includes the time it takes for this configured method to finish processing, not when the method is invoked.
- Follow the instructions that display for the option you choose. Note the following points:
- You configure the class/method option using the standard method selector. See Configure Instrumentation for more information about identifying classes and methods in the AppDynamics configuration.
- For the last thread on the tier approach, first, give a name for the transaction configuration and choose the tier.
- Choose the business transaction where the configuration applies.
The threads in the logical transaction processing flow must be traceable by AppDynamics, including the thread that contains the end-point method. If needed, configure custom thread correlation to ensure that all threads are properly traced. For more information on thread correlation, see Configure the Thread Correlation in Java Agent and Thread Correlation for .NET.