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


Skip to end of metadata
Go to start of metadata

When you organize your web site users' most important activities into business transactions, you get the maximum benefits and the shortest mean time to resolution (MTTR) from AppDynamics Application Performance Mangement.

To get optimal benefits, make sure that your business transactions describe the traffic that you need to monitor and that they do not monitor extraneous, unimportant traffic. Leverage the auto-discovery mechanism and then fine-tune the business transactions to best reflect your organization's needs.

Planning for Business Transactions

You can install AppDynamics and review the auto-discovers business transactions in your environment and then fine-tune the configuration to focus on the transactions of most interest.  Alternately, you can do upfront planning to select and name the operations you want to monitor. For example, you could:

  • Interview the teams responsible for each application component or module to identify the key 5-20 operations that they feel are important to monitor. Identify which key operations must work well for the application to be successful. Ask questions about each operation such as:
    • What is the business flow it represents?
    • What information and metrics are expected?
    • Who is interested and why?
  • Map the identified operations to the appropriate business transaction entry points. The entry point to a business transaction is typically a method that begins every time the user request is invoked. Entry points are described at Business Transaction Entry Points.

As you learn more about which transactions give you the most useful information about your application, you can further refine the detection configuration. See Refine Business Transaction Configuration.

The most important factor for identifying business transactions is functionality. When you analyze user requests, you can produce a manageable list of functionality that is related to service levels. 

For example, in an e-commerce application the individual requests that "add items to the shopping cart" can be tracked as the "Add To Cart" business transaction. For a web portal or content site, you could define business transactions by the category of the content, such as "Politics", "Sports", etc. You could also create more granular business transactions, such as sub-transactions of "Sports" based on the type of sports.

The easiest way to determine the optimal number of business transactions is to consider the following:

  • The number of unique types of requests present in the application
  • The number of service levels per business transaction

AppDynamics recommends that you have only as many service levels as are necessary for a particular transaction. For example, a Login transaction represents the performance characteristics of all users who login to a system. The service level for a Login operation for any given time indicates the performance of the transaction. This data translates directly to what end users experience while logging in.

For web traffic, every unique URL is not a business transaction. Multiple URLs will map to the same type of request and therefore map to the same business transaction.

Tip: One technique for deciding which business transactions are important is to look at the default Business Transactions list to see what AppDynamics discovers by default and sort them by the Calls or Calls/Minute columns

  • No labels