MENU
Features
Home > Features
Reset filters
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.
24/7 Performance Overview
The dashboard gives a 24/7 overview of the performance in a selected time range. It shows real-time critical information about the ADF application’s performance. Monitor your service level agreement (SLA): What is the end-user experience? Are response times within SLA boundaries? Or are they well outside SLA boundaries and is it seriously problematic? What is the error rate? What is the health of the JVM memory? Is immediate action required?
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)
Details Response Times
HTTP response times can be analyzed over the selected time range. This makes visible when the load is high (and how high), how the response times are distributed over the categories (very slow, slow and normal) and when there are performance problems (more red and yellow colored parts of the bars). When there is more red (and yellow) colored parts in the bar chart (top right) this should be a trigger to drill down to this hour for further analysis in order to find the root cause.
Network Time to and from the Browser
Troubleshoot network problems. Network time is the time that it takes to send a HTTP request from a browser (http request network time) to the application server and from the application server back to the browser (http response network time). Read more here.
Time spent in Layer
The dashboard shows several overview and detail graphs that shows the layer (database, webservice, application server, network/browser loadtime) where process time is spent of your ADF application. It traces key ADF actions across tiers and services to provide end-to-end visibility and automatically maps each tier to easily visualize the relationship between them.
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.
Browser Load Time
Browser load time on the end-user (client) side. This is the process time that a browser needs to build up the DOM tree and load the page. Detect pages that have a long browser load time. 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.
Errors/Faults Overview
Insight in the number, type and severity of errors that happen in a test or production environment is crucial to resolve them, and to make a stable ADF application that is less error-prone. Application errors (and their stack traces) are often hard to retrieve or take a lot of time to find. Project teams commonly depend on the reports of end-users and testers, and they typically do not report all errors or provide insufficient information about them. Development, QA and operational teams can drill down to the error messages, their type, severity, and their stack traces to quickly troubleshoot errors and make the application more stable. Read more here.
Error Stacktraces
From the Errors overview you can drill down to the error stacktraces and their ADF callstack. This combination is unmissable to solve complex errors and their root cause. Read more in this blog article.
Time spent in Webservice Calls
Time spent in webservice calls is shown on the main dashboard page. All webservice calls are instrumented and visible on the ADF callstacks. JAX-WS webservices, Apache CXF webservices and the ADF EMG XMLDataControl are supported.
HTTP Request Metrics
The monitor retrieves all HTTP requests down to the smallest details for further analysis; Http Response Time, Time spent in Network/Browser Load Time, Process time by Applicationserver, Time spent in database time spent in webservice, User ID, Click Action (Button/Link clicked on), Timestamp, URI, Managed Server, link to zoom in session details, ECID, Organization, e.g.)
Time Range
There is common functionality; in every page a time range can be selected (5 minute, hour, day, week, month). You can drill down or roll up to any time range, or navigate to next or previous time range. There is also an option for a custom time range; this is useful to evaluate load tests.
ADF Callstack/Snapshot
An ADF callstack or snapshot gives visibility into which ADF method caused other methods to execute, organized by the sequence of their execution. A complete breakdown of the HTTP request is shown by actions in the ADF framework, with elapsed times and a view of what happened when. The parts of the ADF Request that consume a lot of time are highlighted and indicated with an alert/warning signal.
Performance by Click Action
A Click action is the actions that users have taken within the UI. This mostly relates to physical clicks on ADF Faces components such as buttons and tabs, but it also reports scrolling events, table and graph draws and more. It can help answer that particular question – “What did you do before you got the error?” for the operation/support team to troubleshoot problems.
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.
Select/Filter on Managed Server
Drill down into a specific Managed Server. Compare performance between Managed Servers or Monitor All Together.
End-User Metrics
There are several overviews of summarized end-user metrics. For example worst performance by user, top users by requests, and number of errors by users.
Filter on User ID
In case specific end-users are complaining about today’s or yesterday’s performance, the monitor helps to quickly troubleshoot. With the monitor you can filter all requests and its details on a specific end-user ID and analyze/troubleshoot the problems. The true picture for every individual user is visible. Every user interaction (like clicks and scrolls) is logged. You can trace every session of your end-users experience.
Use in JDeveloper during Development
The ADF callstacks can be printed in JDeveloper during development. This enables developers to diagnose and solve performance problems at an early stage and to build an efficient, responsive ADF application before it goes into production. For every HTTP request a call stack is printed; a call stack provides visibility into which ADF methods caused other methods to be executed, organized by the sequence of their execution. A complete breakdown of the ADF request processing, including all ADF method executions, along with elapsed times is printed, organized by lifecycle phase.
Thread CPU time (User and System)
Monitoring the amount of time the CPU spends on executing a thread of individual requests is extremely useful. With this we can determine their load on the CPU’s of the underlying system. It gives a clear indication how expensive certain requests are in terms of CPU cost. Read more in this blog article.
CPU Time Consumption
It is useful to get insight in the CPU time consumption of the ADF application, and especially when the load is high. Different releases can be compared, and ADF developers can try to bring down (unnecessary) CPU time of expensive, ‘CPU burning’, operations. Read more in this blog article.
Thread Waited and Blocked Time
In the world of Java threads, we often can explain poor performance or hiccups. It can be that some threads were waiting on some resources or were being blocked. We can this for each HTTP request in detail. Read more in this blog article.
Linux Load Averages
An excellent way to look at the load of the whole system is the Linux load averages. This shows the running thread (task) demand on the system as an average number of running threads on the processors plus waiting threads (waiting threads queued to the available processors). Read more in this blog article.
