Warnings

Automatic SLA and Health KPI Warnings

Automatic SLA and health KPI warnings. Error Percentage, Very Slow Requests Percentage, AVG Server Process Time, JVM garbage collection, jvm and system CPU load, OS memory, database, webservice, application server, network, and browser. Read more in this blog article.

Summary of Response Times

In the top left section of the dashboard a summary of HTTP requests response times is shown for the selected time range. It shows 4 categories:

• Normal (well within the SLA range)
• Slow (somewhat outside the specified SLA response time)
• Very slow (well outside the SLA boundaries, considered seriously problematic)
• Errors (Number of Errors/Exceptions)

JVM CPU Load and System CPU Load

The CPU load percentage of the JVM, and the total CPU load percentage of the whole underlying operating system. A high CPU usage rate and memory usage may indicate a poorly tuned or designed application. Read more in this blog article.

JVM Heap and Garbage Collection

An important aspect of performance management is a healthy JVM. The ADF Performance Monitor shows realtime or historic JVM heap usage and JVM garbage collection times. If garbage collections are running longer than a configurable threshold (for example 20 seconds) a warning sign is shown. This is often an indication of a problem – such as a freeze of all current requests because the JVM cannot clear enough memory. This should be a trigger to drill down to for further analysis in order to find the root cause.

Troubleshoot Slow ViewObject Query

A threshold can be set to log ViewObject SQL queries and their complete runtime statement including applied ViewCriterias and bind parameter values. Analyze slow queries and problems executed against the database.

Warnings and suggested solutions

During the whole application lifecycle, QA teams can make sure problems are found and dealt with. They can routinely check to ensure the application meets the desired quality. In the callstacks clickable warnings signs (Figure 11) are shown for slow executions and detected inefficiencies. These give a quick help with suggested solution(s) and a link to more detailed help.

Worst ADF BC and ADF Model layer executions

In various overviews the worst performing parts of the ADF Business Components and ADF Model layer are indicated. Bottlenecks and the weakest chains are shown here. For example example the ADF BC overview it shows very slow, slow and normal ADF BC executions:

• ViewObject queries
• EntityObject DML operations
• PL/SQL procedure/function calls
• ApplicationModule Pooling passivations / activations
• ApplicationModule Transactions

ApplicationModule Pooling Performance

It is important to choose the right combination of ApplicationModule pooling parameter values to make the application scalable. This overview gives insight in the effect of these parameter values (how often passivations and activations happen, how long their AVG and total execution time is). QA teams can research and experiment with these parameter settings during load tests and evaluate the performance results in the monitor. The monitor also detects which ViewObjects data are being activated and passivated.

Total Execution Time of Worst Performing Executions

The performance impact of frequent invoked executions can be much higher than executions that occur only a few times but are very slow on average. There are additional overviews for the total execution time.

ADF Business Components Memory Analyzer

Like other web applications, ADF applications potentially use a lot of memory. To prevent memory over-consumption (often a pain-point in ADF applications) the ADF BC Memory Analyzer detects how many database rows are fetched by ADF ViewObjects. When too many rows are loaded into memory a warning sign is shown with suggested solutions. Read more here.