The AMIS ADF Performance Monitor is an advanced tool designed for measuring, analyzing, improving, and checking the performance of Oracle ADF applications. The monitor can track and collect crucial (production) performance information of the application’s runtime ADF components that are not standard provided by Oracle. It helps development, QA, and operation teams to detect, analyze and resolve common and less common issues in response times and resource usage of ADF applications.
Last week an overview video was published. This blog publishes a new whitepaper that gives detailed information about the architecture and implementation of the ADF Performance Monitor.
The first version of this tool (ADF 10g version) was already released in 2009. One year later the ADF 11g version of the ADF Performance Monitor was released and since then many new versions have been released. In 2011 we added a separate dashboard reporting application to the toolset. Last years the monitor has been improved with a new UI design and extended with many new and advanced features.
Currently the ADF Performance Monitor has been implemented in more than 15 Oracle ADF applications over the world. The monitor has proven to be very useful in many ADF projects. Read the quotes of ADF experts and managers.
New whitepaper published
Whitepaper ADF Performance Monitor – this document gives more information about the architecture and implementation of the ADF Performance Monitor.
Content of the whitepaper:
- Executive overview
- Oracle ADF applications and performance
- ADF Performance Monitor overview
- Use in JDeveloper
- Use in test and production environment
- Dashboard reporting application
- Summary and details HTTP response times
- ADF framework call stack
- Warnings and suggested solutions
- Worst performing executions in ADF BC and model layer
- Error stacktraces
- JVM performance
- Product architecture
- Turn on/off at all times
- Monitored Events
In development, test and production environments, the ADF Performance Monitor provides similar functionality as the callstacks of the Oracle ODL Analyzer (by ADF request). The Oracle ODL Analyzer can be useful in the development stage, but can’t be used in test en product environments because of the amount of logging generated and the significant performance overhead. The ADF Performance Monitor records the performance with a very low overhead (less than 4%, caused by the detailed collection of performance metrics). An example of a callstack in the ADF Performance Monitor is shown in the image below. In this case the bottleneck is a slow ViewObject query of 18033 milliseconds (with usagename HRService.EmployeesView1) :
In addition to that, the monitor reports overviews of the worst performing ADF Business Components (shown in the image below), BindingContainer and webservice executions and the possibility to drill down. Extensive help is available in the monitor on how to interpret the metrics. Also JVM metrics and application errors are reported. SLA monitoring (load and HTTP request response times) is possible. Because of the low performance overhead, it is safe to use the ADF Performance Monitor in production environments. The metrics collection can be dynamically turned on and off (at runtime) at all times. When the monitor is turned off there is no performance overhead because the metrics classes are not active. More detailed information is available in the whitepaper published in this blog.
With the ADF Performance Monitor, development, QA and operation teams get insight into what is happening inside their ADF application throughout the whole application lifecycle. With this insight they can circumvent frequent performance problems, use best practices and deliver a responsive and scalable ADF application.
Detecting and Analyzing a High ADF BC Memory Consumption
Recently a new feature was added: a kind of ADF BC memory recorder and analyzer. It detects and warns when too many rows are being fetched (from the database or webservice) and held in ADF BC memory. With this feature you can investigate and address memory over-consumption. Memory over-consumption can lead to very long running JVM garbage collections, a freeze of all current requests or even OutOfMemoryErrors.
More information is available on the the AMIS site.