Configuration

Transactions are configured in the recording settings. When you edit a VM group or a VM pool, the first displayed step in the wizard shows the transaction settings.

If no transactions are defined for a nested VM group, VMs get their configuration from the nearest ancestor group where transactions are defined. The "All VMs" configuration always has associated transaction definitions and is always a successful last stop for this search in the hierarchy.

When a nested group overrides transaction settings, it overrides all of them and there is no merging with the settings of a parent group. If you want to reuse selected definitions from a parent group,  save them to a set and  include them in the configuration of the nested group.

A transaction definition selects a segment of all possible transactions in its subsystem. For example, web transactions are defined with a URL wildcard or regular expression. Each transaction definition has an optional associated naming scheme and optional associated policies. For both naming and policies, perfino keeps looking in the list of defined transactions until it finds a matching entry.

This allows you to define a series of transaction definitions that all have different naming schemes while keeping common policy definitions for a group of transaction definitions. Keep in mind that the transaction matching in perfino takes the first match, so more generic filters should be lower in the list of transaction definitions.

There are a number different transaction types in perfino. All types fall into two different categories: predefined transaction types and custom transaction types.

Predefined transaction types

The most common mechanism that starts a business transaction is via a URL invocation. In perfino, this is called a web transaction. In the default configuration, perfino intercepts all URLs and creates transactions for them. For your application, you will want to limit the intercepted URLs to those that are meaningful from a business perspective. To do that, you can remove the transaction definition for the URL wildcard "*" and add your own specific transaction definitions.

Another way to limit transaction matching is to use the "Discard" flag. In that case, any matching URLs will be excluded and no further matching will take place.

In the list of transaction definitions, the filter expression will be shown as the name of the transaction definition. Often, this is not descriptive enough. Use the "Custom description" check box shown above to enter a meaningful name. This is only used in the configuration and not in the displayed data where the transaction naming determines the name of the transaction.

The name of a transaction is composed of a chain of naming elements. The list of available naming elements depends on the transaction type. For web transactions you can use specific elements like "URL query parameter" and "URL segments".

An important consideration when defining complex transactions is what kind of nested transactions should be allowed. Perfino does not record a directly nested transaction that has the same name. More restrictive options are to prevent nested transactions

• that match this entry

  No nested transactions will be created if the nested transaction originates from this transaction definition.

• with the same group name

  If you select this option, you have to configure a group name for this transaction definition. For example, you might have different entry points for a particular business transaction from a web transaction and from an EJB transaction, and the URL handler always calls the EJB. If you do not want to see the EJB as a nested transaction, you can assign the same group name to the web transaction and the EJB transaction.

• of the same transaction type

  This option is suitable if you only want to see entry points and not the internal structure. For example, EJBs will often call other EJBs. This reentry mode prevents a tree of nested transactions in that case.

• all further entries

  Use this option to prevent any kind of nested transaction if a transaction is created from the current transaction definition.

The reentry inhibition only applies to the transactions that would be directly nested. If a nested transaction is allowed, its own reentry inhibition setting will be used for the next nesting level.

EJB transactions are created from calls into public methods of an EJB that is annotated with @Stateful, @Stateless, @MessageDriven or @Singleton. Spring service invocations are for calls into beans that are annotated with @Component, @Controller, @Repository or @Service. You can limit transaction recording to a subset of those transactions for both EJB and spring transactions.

When creating transaction definitions, both these transaction types can be filtered with respect to class or package name. The discard mechanism is useful to exclude certain classes that are not generating significant data. By default, perfino shows all EJB and Spring service invocations.

RMI transactions handle incoming RMI calls into a VM. Like for EJB and Spring transactions, you can use a class filter to include or exclude implementation classes. The default configuration in perfino shows all RMI invocations.

Custom transaction types

There are many frameworks where specific interceptions can capture all important business transactions. Also, your own code will often be structured in such a way that a small set of methods will map to your business transactions. perfino offers three mechanisms for monitoring these cases. Configuration of these transaction types is more elaborate so that each of them has its own chapter in the advanced topics.

For an annotated invocation transaction, you specify a particular annotation class name. In the further configuration you can decide whether the annotation should apply to classes or methods and how inherited classes should be handled.

DevOps transactions are defined in your code with annotations supplied by perfino. While the naming is completely specified with those annotations, the policy must be configured in the perfino UI. This is the most maintainable way to define complex transactions. See the advanced topic about DevOps transactions on how to add them to your project.

If you cannot modify the code that should be monitored, POJO transactions allow you to specify all the same interceptions as DevOps transactions directly in the perfino UI. See the detailed explanation of POJO transactions for more information.

Call tree and hot spots

perfino builds a call tree from all recorded transactions. A call tree is a cumulated data structure that captures all the different sequences in which transactions are nested. If transaction C is called within transaction A and also within transaction B, it will occur twice in the call tree, once as a child of A and once as a child of B. Each of these sequences can occur many times, increasing the invocation counts along the corresponding paths in the call tree.

The numbers for each transaction - total time, invocation count and average time are displayed for the selected period. If the period is not fully measured, perfino will tell you the covered percentage at the bottom of the view. For example, when starting up the perfino server, the current hourly interval will not be fully measured until a full hour has passed. Similarly, if you stop the perfino server for some time, this will leave holes in the history with incomplete intervals at both sides.

Hot spots are the inversion of the call tree, where all occurrences of each transaction are summed and shown with their backtraces. The invocation counts and execution times in backtraces do not refer to the transactions, but rather to the number of times the hot spot was called along this path.

To emphasize the point about backtraces, all hot spots have a child node called "Cumulated backtraces". Searching for transactions is done with the filter bar at the bottom of the view. Many views in perfino have such a filter bar.

In order to give you a chronological context for the selected interval in the call tree and hot spots views, a transaction timeline is shown at the bottom where the current interval is highlighted. You can also use this timeline to select another interval by clicking on a data point. When you display a timeline for a single selected transaction, the total transaction timeline is replaced and can be restored by clicking on the close button.

Transactions in the dashboard

Frequency, average time and total time of your most important transactions are key measures for your application. To give you a quick overview in that respect, the dashboard contains a transaction table that shows the most important transactions with these numbers from the last hour or the last day. You can sort by the different columns and the configure button at the top of the table allows you to select which of the columns should be used as the "primary measure" and show a histogram next to the numeric values.

In the transaction table, transactions are not shown in the form of a call tree, but completely flat. This means that it also shows transactions that are not entry points but only invoked as nested transactions. For a detailed analysis, click on the transaction row to go to the call tree view in the "VM data views" tab.

The drop-downs at the top provide three ways to adjust the range of the displayed transactions in the dashboard:

• Period

  By default, the dashboard shows the last running hour. Alternatively, you can switch to the last running day.

• Request type

  By default, all transactions are shown. Alternatively, you can restrict the display to web transactions only.

• VM group

  By default, all monitored VMs are shown. With the "VM group" drop-down, you can restrict the displayed data to a particular VM group and its nested groups. For example, if you select group "A/B", then all VMs that are contained in "A/B" are shown, but also VMs in "A/B/C".

Overload protection

A common problem with new perfino installations is that web transactions have not yet been configured to map to high-level business transactions. As a consequence, too many distinct transaction names are being generated. In that case, perfino's overload protection mechanism caps the maximum number of transaction names and sends you an inbox message with instructions on how to fix this condition.