Last week I blogged in part 1 on our major new version of the ADF Performance Monitor – version 9.0. It was about monitoring the CPU load of the JVM process and of the whole underlying operating system. It was also about the total used and free physical (RAM) memory of the whole system, and the Linux load averages that provides an excellent view on the system load.

This blog (part 2) describes more new features. The CPU execution time of individual HTTP requests and click actions is now available. “What request/click action in the application is responsible for burning that CPU ? ” That question you can now answer with the monitor. The monitor gives a clear indication how expensive certain HTTP requests and click actions are in terms of CPU cost. Further we added browser (user-agent) metrics for each request. We also improved the ADF callstacks (snapshot that gives visibility into which ADF method caused other methods to execute, organized by the sequence of their execution and execution times).

CPU User and System Time of Individual Requests

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. In the HTTP requests overview, for each request (or click action) the User CPU time and the System CPU time is shown:

• User CPU time is time spent on the processor in user mode running your program’s code (or code in libraries) of the HTTP request/click action (thread).
• System CPU time is the total time spent running code in user mode as well as in kernel mode on behalf of the program request (thread).

See also CPU user and kernel mode explained on Wikipedia. A very high value (for example more than 5 seconds) indicates that very expensive program code is executed.

For example:

• expensive long loops through large collections in Java code
• retrieving/fetching large collections of database rows from the database. And do some processing for each row.
• repetitive ViewObject queries
• repetitive (redundant) ViewAccessor executions
• rendering of tables with many columns and rows in the render response phase.

In this case you should investigate these further, for example by looking into the ADF callstacks of the ADF Performance Monitor what is happening behind the scenes.

When you’re in the cloud or considering moving to the cloud, you might want to check which requests/click actions are responsible for high ‘CPU burners’. If one or two click actions are burning 80% of your total CPU resource, then that’s an easy opportunity to save money – rather than to spend it in the cloud.

CPU User Time and CPU System Time of ADF Click Actions

CPU metrics have been also added to the ADF click actions report overview (aggregated click actions). This overview shows the most time-consuming click actions in total. Again by CPU User time and the CPU System time. Now you can inspect all greedy CPU click actions, those responsible for burning high CPU time.For example, in the following day overview of ADF click actions we see two CPU burners:

1. A fetch action of an oracle.adf.RichTable component with ID loc_t1 and the display name locationsTable. We can see a lot of total thread CPU time (more than 20 minutes), and also the average thread CPU time is high: 25,13 seconds (!). In this case this was caused by a rendering a very big table; this table has more than 50 columns and hundreds of rows.
2. An action from an oracle.adf.RichButton component with ID b1 and the display name saveRequestMetrics. The total thread CPU time is more than 3 minutes, and also the average thread CPU time is very high: 100,67 seconds (!). This was caused by an extremely long loop in Java code.

If you have a particular click action on a page that consumes a lot of CPU time, the next step is to analyze the program code of this click action to see what is happening. You can drill down to the requests overview to inspect individual requests. Also, you can inspect the ADF callstacks what is happening behind the scenes in the ADF internals.

To get more insight in worst performing click actions it is useful to look over a longer time period to exclude incidental disruptions, hiccups. Then you have more aggregated metrics to base your analysis on. For example from a month overview, this time from a production server:

Browser Type Information (User-Agent)

Another new feature of the ADF Performance Monitor is browser type information. For each HTTP request the monitor shows in an icon which browser type was used. This is useful when investigating problems, browser issues, or to explain slow browser render time, especially when old browsers or other inefficient browsers are used :

In the screenshot you can see many HTTP requests, ordered from slowest response time descending, with many metrics for each request. Like execution time, timestamp, execution time spent in layer (database, webserice, applicationserver, network, browser), user ID, ADF Faces component ID & type, ADF event type, ADF Faces component label, region viewID, managed server, and many more metrics.

Now the browser type is added – in the screenshot Internet Explorer, Chrome, and Firefox. If you hoover with your mouser over the browser icon, detail information of the user-agent is show (not in picture). See the importance of the browser type in this blog.

Improved ADF Callstacks

The ADF callstacks (or snapshots) give 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.

They are improved and provide even more detail information on the execution of ADF internals. For example, when ApplicationModules are created, when ApplicationModules from the AM pool are being checked out, etc.:

Part 1

In part 1 of this blog I wrote on other new features of this major new release; the CPU usage of the JVM, the total CPU usage of the whole underlying operating system, the total used and free physical (RAM) memory of the whole system, and the Linux load averages.

Free 7 Day Trial

We have also a free 7-day trial, you can request it on this website at our main page (adfpm.com).

License

You can purchase a license of the ADF Performance Monitor at our order page.