View source | Discuss this page | Page history | Printable version   

Monitoring with AppDynamics


Finding Performance Issues

The purpose of AppDynamics is to check application health in terms of performance and help to pinpoint the causes of possible problems.

There are two main techniques to find this kind of problems: proactively and reactively, both of them explained in the following sections.

Continuous Monitoring

Even before user notices slowness or big issues arise, it is possible to analyze which are the slowest parts in the application, being those candidates to be optimized.

Slow transactions

Slowest transactions can be detected from Application Dashboard > Top Business Transactions Tab. From this view you can have an idea of which are the most used transactions, which are the ones consuming more time and which of them have a bigger rate of slow, stalls and errors. These are the candidates to review, in order to try to optimize them. From this view you can navigate to transaction snapshots for each of them to gather more information about the most expensive spots of each of them.

Another interesting view is Slowest Database Calls tab, here top 10 slowest queries are listed, if snapshots are taken you can also see which Business Transactions executed these queries.

Baseline Comparison

You can compare performance (Load and Response Time) during a time range with a base line. This comparison can be done globally or per Business Transaction and allows to understand the behavior compared with the average.


In addition to performance issues, AppDynamics can also help to detect and pinpoint errors in code.

When a request throws and exception or logs an message with a level of error or greater, the transaction associated to that request is marked as erroneous and a snapshot is taken.

From the Business Transactions list window, you can see the percentage of errors per different business transaction. Once you have detected the Business Transaction you want to check the errors for, open it by double clicking in its line and go to Errors tab. Here you will see a graph of when the errors occurred and a list of snapshots obtained for erroneous transacations. Opening these snapshots and drilling down allows to see the Error Details section of the snapshot, where the error stack trace is shown.

False positives

Because of what is considered as error, there might be some false positives that do not require of any action. For example, when a processed invoice is tried to be modified, Openbravo throws an error at DB level which is logged, detecting this transaction as erroneous. In this case the it is an error because the user tried to do something not allowed, but the code itself is OK.

It is possible to fine tune the messages and exceptions considered as error in order to minimize the number of false positives. This can be done from Configure > Instrumentation > Error Detection tab.

Fine Tuning BTs

AppDynamics for Openbravo delivers some predefined generic BTs which make sense for general Openbravo monitoring.

It is possible that for a single BT some of the request to correctly perform and some other to be slow. This can be due the fact BTs group several different requests, for example DataSource BT groups all the requests executed to populate the grids in any tab, but some tabs could perform fine whereas some others can be slow. In order to better understand the problem these BTs can be split in several, ie. one for the tab known to be slow and another for the rest. This allows to better track the issue, and compare times before and after a fix is applied.

Similarly, HTTP Data Collectors can be customized based on concrete needs.

Warn-icon.png   AppDynamics limits to 50 the number of different Business Transactions per Application Agent in order to minimize performance impact in server. If new transactions are defined, check this limit is not reached, if so some other transactions should be removed.

Proactive Monitoring

AppdDynamics is able to proactively monitor Openbravo instance, creating automatic notifications as soon as something starts going wrong.

Health Rules

AppDynamics allows to set up Health Rules, when these rules are violated:

Reactive Monitoring

When the system is known to poorly perform during a period of time, reactive monitoring helps to determine where the problems are.

The actions taken to look for the problems are the same as the defined for the Continuous Monitoring but narrowing time range down to the period the problem was noticeable.

Addressing Performance Issues

When performance problems are found, first step is to detect where the issue comes from. Performance degradation can mainly be caused by:

Reporting Performance Issues

When a performance problem is found in Openbravo core code. The way to report is:


AppDynamics computes baselines with statistical information of load and response time for each Business Transactions as well as for the whole Application.

These base lines can act as a benchmark to compare with, being possible to know how the application, or a business transaction, behaves in comparison with the average. This comparison can be seen in Application and Business Transactions Dashboards.

After a performance issue is fixed, the expected result is response time for the involved transactions to start being smaller than the base line.

Compare Releases

After a performance bug fix is deployed or after updating to a new version of Openbravo or of a module, it is possible to compare the performance for the whole application or a concrete Business Transaction.

This window is accessed from main menu > Analyze > Compare Releases.

Here graphs for two different time ranges can be compared. Select in the first one a time range previous to the fix and in the second one a time after it is applied.


Retrieved from ""

This page has been accessed 6,639 times. This page was last modified on 30 October 2014, at 08:02. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.