AMIS Oracle and Java Blog » Frank Houweling https://technology.amis.nl Friends of Oracle and Java Wed, 01 Apr 2015 18:48:08 +0000 en-US hourly 1 http://wordpress.org/?v=4.1.1 ADF Performance Monitor: Measuring Network Time to Browser and Browser Load Time https://technology.amis.nl/2015/03/29/adf-performance-monitor-measuring-network-to-browser-and-browser-load-time/ https://technology.amis.nl/2015/03/29/adf-performance-monitor-measuring-network-to-browser-and-browser-load-time/#comments Sun, 29 Mar 2015 15:57:49 +0000 https://technology.amis.nl/?p=35040 Share this on .. Recently we added a great new feature to the ADF Performance Monitor: network and browser load time information. Now you know exactly every end-user experience of your ADF application, in real-time. You can quickly resolve any performance bottlenecks with this end-to-end visibility. You can even drill down into an individual user to analyze [...]

The post ADF Performance Monitor: Measuring Network Time to Browser and Browser Load Time appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Recently we added a great new feature to the ADF Performance Monitor: network and browser load time information. Now you know exactly every end-user experience of your ADF application, in real-time. You can quickly resolve any performance bottlenecks with this end-to-end visibility. You can even drill down into an individual user to analyze the experience – to understand the ADF app behavior. The dashboard is improved with several overview and detail graphs that shows the layer (database, webservice, application server, network/browser loadtime) where the time is spent of your application. This is very useful to troubleshoot problems.

The ADF Performance Monitor is an advanced tool specifically build for ADF applications and is aware of the intricacies of the ADF framework. 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. This Tracing provides deep visibility into the cause of application performance issues down to the tiniest detail. Click here for more information.

Network Time and Browser Load Time

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). The browser loadtime is the time that a browser needs to build up the DOM tree and load the page.

database_appserver_network_client

Normally, the combination of the network time and browser load time should not be more than ± one second.

Network Time/Browser Load Time in the ADF Performance Monitor

Several overview graphs are added to the main dashboard. At the day overview, it shows for each hour of the day (right bottom) the layer where the time is spent. It shows the time spent in the database, webservice, application server, and network/browser load time:

ADF Performance Monitor Day Overview - Slow Network Time at 11 am

At the top right graph (hourly overview of day performance) we can see a lot of red in the bars. Specifically from 11:00 to 12:00 – apparantly there were many very slow requests. In the graph at the right bottom we can now explain what happened; there were network problems. After talking to the infrastructure department – this was indeed the case. They were very busy with maintanance and were not aware (!) that end-users were suffering from there work.

We can drill down to an hour overview:

ADF Performance Monitor Hour Overview - Slow Network Time at 11 am

Also, we can zoom in into a specific managed server of our 12 server cluster (called regi_adf_server1) from the dropdown list:

ADF Performance Monitor Hour Overview - Slow Network Time at 11 am - filtered by managed server

We can see here that during the whole hour there were network problems (graph right bottom).

By clicking on the bars in the menu, we can zoom in more to a five minute overview (11:40-11:45):

ADF Performance Monitor Five Minute Overview - Slow Network Time at 1140 am

In the top graph we see all individual http requests in managed server regi_adf_server1. Again, the stacked bars show the time spent in database, webservice, application server, and network/browser load time (purple). We can see that many end-users have to wait ± 5 seconds – on pure network time (!). Note that The JVM is not the problem and is working fine (bottom graph).

The next day the network problem was resolved. We can see this in the following hour overview graph were there is much less purple colour (right bottom):

ADF Performance Monitor Hour Overview - Normal at 11 am - filtered by managed server

In the HTTP request popup we can also select a specific end-user an monitor his/her experience. The client response time is the time including everything; the app server process time, the network to browser and browser load time. We can see that in this case the client response time was even more: ± 9 seconds for each HTTP request (!). This user (and organisation) was complaining and calling our support desk where we could monitor and investigate this end-user experience:

End User Experience - HTTP Requests2

You can get here more information on the ADF Performance Monitor.

A one month trial version is available on demand (write an email including the specific ADF version you are using).

Special thanks to my colleage Paul Swiggers for helping implementing this great new feature.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Performance Monitor: Measuring Network Time to Browser and Browser Load Time appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2015/03/29/adf-performance-monitor-measuring-network-to-browser-and-browser-load-time/feed/ 0
Creating Intuitive & Interactive Dashboards with the ADF Data Visualization Components https://technology.amis.nl/2014/12/18/creating-intuitive-interactive-dashboards-adf-data-visualization-components/ https://technology.amis.nl/2014/12/18/creating-intuitive-interactive-dashboards-adf-data-visualization-components/#comments Wed, 17 Dec 2014 23:20:02 +0000 http://technology.amis.nl/?p=33394 Share this on .. Last week I presented at the UKOUG’14 conference on creating intuitive & interactive dashboards with the ADF Data Visualization Components. Frequently end-users are overwhelmed with too much and confusing information displayed in rows and columns. It can be difficult to quickly get the relative significance. This session discussed how to create intuitive, interactive dashboards [...]

The post Creating Intuitive & Interactive Dashboards with the ADF Data Visualization Components appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Last week I presented at the UKOUG’14 conference on creating intuitive & interactive dashboards with the ADF Data Visualization Components. Frequently end-users are overwhelmed with too much and confusing information displayed in rows and columns. It can be difficult to quickly get the relative significance. This session discussed how to create intuitive, interactive dashboards made with the ADF Data Visualization Components. You can use of the power of visualization to present information; to call the end-user to action instead of presenting raw data – as we frequently do today. Visualizations can be used to help end-users focus on what is relevant: aggregates, exceptions, trends, comparisons e.g.

This blog posts the slides from this session.

dvts

 

The agenda of this session:

  • Why data visualization is important
  • Examples where DVTs are used
  • Graph demo: ADF Performance Monitor
  • Basic steps creating a graph (ADF11g)
  • Special features
    • Mouseover info
    • Alerts,
    • Reference line,
    • Animation 3D,
    • Clicklistener,
    • Hide and show,
    • Dual graphs
  • Advanced Graph Examples
    • Bubble
    • Spark
    • Treemap
  • Other Tips & Challenges
  • 12.1.3 DVT Components

You can download the slides here UKOUG_Creating Intuitive & Interactive Dashboards with the ADF Data Visualization Components

 

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post Creating Intuitive & Interactive Dashboards with the ADF Data Visualization Components appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/12/18/creating-intuitive-interactive-dashboards-adf-data-visualization-components/feed/ 0
Instrumenting, Analysing, & Tuning the Performance of Oracle ADF Applications https://technology.amis.nl/2014/12/12/33312/ https://technology.amis.nl/2014/12/12/33312/#comments Fri, 12 Dec 2014 16:21:08 +0000 http://technology.amis.nl/?p=33312 Share this on .. Last week I presented at the  UKOUG’14 conference on instrumenting, analyzing, & tuning the performance of Oracle ADF applications. Instrumentation refers to an ability to monitor or measure the level of a product’s performance, to diagnose errors and to write trace information. Instrumenting gives visibility and insight of what is happening inside the ADF [...]

The post Instrumenting, Analysing, & Tuning the Performance of Oracle ADF Applications appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Last week I presented at the  UKOUG’14 conference on instrumenting, analyzing, & tuning the performance of Oracle ADF applications. Instrumentation refers to an ability to monitor or measure the level of a product’s performance, to diagnose errors and to write trace information. Instrumenting gives visibility and insight of what is happening inside the ADF application and in the ADF framework (what methods and queries are executed, when and how often). These runtime diagnostics can be very effective in identifying and solving performance issues and end-user behavior. This enables developers and operations teams to quickly diagnose and solve performance problems in a test and production environment. This blog posts the slides from this session. It  shows how you can instrument your own ADF application and build your own performance monitor.

Gauges_real_world

Gauges_real_world

Why is instrumentation important?

  • Many applications are like a smoke screen; it is very unclear what is happening in the background. Where should we look for bottlenecks ?
  • End-users do not accept slow applications anymore
  • Operation teams and developers need visibility:
    • Are response times within SLA agreements?
    • What are the exact pain-points and weakest links of the ADF application ?
    • Are there errors? What type/severity of errors?

The Agenda of this session:

  • What is instrumentation
  • Why instrumentation is important
  • Cost of tracking
  • Analyzing and tuning
  • Oracle ODL Analyzer
  • Build your own performance monitor
    • What you can instrument – Not ADF specific
    • What you can instrument – ADF specific
    • Five examples how you can instrumentation key spots in ADF applications
      • Instrumenting HTTP Request
      • Instrumenting Errors / Exceptions
      • Instrumenting ADF Business Components
      • Instrumenting JVM memory consumption
      • Instrumenting  ApplicationModule pooling (activation and passivation)

You can download the slides: Instrumenting, Analysing, & Tuning the Performance of Oracle ADF Applications.

 

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post Instrumenting, Analysing, & Tuning the Performance of Oracle ADF Applications appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/12/12/33312/feed/ 0
ADF Performance Monitor: Measuring Slow Network Time https://technology.amis.nl/2014/07/21/adf-performance-monitor-measuring-network-fetchtime/ https://technology.amis.nl/2014/07/21/adf-performance-monitor-measuring-network-fetchtime/#comments Sun, 20 Jul 2014 22:37:15 +0000 http://technology.amis.nl/?p=30593 Share this on .. Recently I was implementing the ADF Performance Monitor at a customer site and doing a detailed performance analysis. This customer had severe (and less severe) performance problems but was unable to pinpoint the exact pain points. Frequently, end-users were complaining because they were experiencing first a very good performance (response times less [...]

The post ADF Performance Monitor: Measuring Slow Network Time appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Recently I was implementing the ADF Performance Monitor at a customer site and doing a detailed performance analysis. This customer had severe (and less severe) performance problems but was unable to pinpoint the exact pain points. Frequently, end-users were complaining because they were experiencing first a very good performance (response times less than a second), and then suddenly experiencing a drop in performance for a certain period of time (an hour or so) with response times between five to twenty seconds.

In this particular case, at the hour overview of the ADF Performance Monitor (from 14:00 to 15:00) we can see the sudden start – and end of this drop in performance. In the top right section HTTP response times can be viewed over the selected time range. This graph 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).Visible is that from 14:10 to 14:40 the response times have increased significantly. This should be a trigger to drill down to this period in the monitor – for further analysis in order to find the root cause.

database_batchjob_prod

We can drill down from an hour to a 5 minute range (14:25 – 14:30) by clicking on the graph in the menu. Now we see an an overview of all individual HTTP request in this 5 minute range on the top graph – with time in WebLogic (blue) and time in database (yellow). We see many long response times between 5 and 30 seconds. We see that most is consumed in WebLogic but we still don’t know where the time is spent exactly. Also we can see from that the JVM (bottom graph) appears to be ‘happy'; the JVM can easily manage the load so the JVM is not the problem in this case:

database_batchjob_5minute_overview

 

The next step is to drill down to so called ‘ADF request call stacks’ in this time range. An ADF request call stack of the ADF Performance Monitor 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 (lifecycle phases, model and ADF BC executions, ApplicationModule pooling, ViewObject query executions,  time to fetch database rows into the ADF app, e.g.), with elapsed times and a view of what happened when. Call stacks are a very useful help to understand specific situations, it shows bottlenecks and where we can avoid bad ADF practices and write more efficient ADF code. The parts of the ADF Request that consume a lot of time are highlighted and indicated with an alert signal.

Slow_fetch_time

After investigating many ADF request callstacks, we we able to detect that the time that was needed to fetch database records by ADF ViewObjects was extremely long. For example, the time shown in this callstack (see image above) to fetch only 173 records into the ViewRowCache of this ViewObject took more than 5,3 seconds and later in the same HTTP request 6,2 seconds (!). And that while the ViewObject query time – method executeQueryForCollection() – took only around 50 milliseconds. Normally, ViewObjects should be able to fetch this number of records in easily only a few milliseconds. ADF always executes this in the following order: first the ViewObject query is executed by the executeQueryForCollection() method. Then, when this method is completed, the database rows of this ViewObject are being fetched. This action and how long this takes is shown in the callstack as ‘Fetching, creating rows for <viewobject instance name>, fetched <xxx rows> ‘.

When the time to fetch rows takes long – and the number of rows fetched database rows is still relatively low – this is a very strong hint that during this request the network between the production WebLogic server and the database seemed to be the bottleneck. This can be the case when they are very far from each other and/or the internet connection is very slow. Or that the network is already very busy.

We knew there was a firewall between the database and the Weblogic server that definitely did not help the communication between these two. But, it turned out that the firewall was not the main problem. It was the periodically database batchjobs (unfortunately executed by the operation team during daytime) that were taking very very many network resources. See the following screenshot from the database Enterprise Manager with metrics from exactly the same time period:

em_networktime

We can clearly see in this picture too that from 14:10 to 14:40 there is many network traffic – caused by a costly database job that was executed by the operation team on that particular moment. The solution is to not execute these batchjobs anymore during daytime :). Now end-users do not have to suffer anymore from these jobs that could be executed in the night as well.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Performance Monitor: Measuring Slow Network Time appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/07/21/adf-performance-monitor-measuring-network-fetchtime/feed/ 1
ADF Performance Monitor: Troubleshooting Test and Production Errors https://technology.amis.nl/2014/04/27/adf-performance-monitor-troubleshooting-test-and-production-errors/ https://technology.amis.nl/2014/04/27/adf-performance-monitor-troubleshooting-test-and-production-errors/#comments Sun, 27 Apr 2014 22:52:53 +0000 http://technology.amis.nl/?p=27550 Share this on .. 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 [...]

The post ADF Performance Monitor: Troubleshooting Test and Production Errors appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

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. Operational teams do not always have the time to monitor for errors in the WebLogic console or the Enterprise Manager or to wade through large log files to manually piece together what happened. To address this issue, errors are collected by the ADF Performance Monitor. 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.

Logging test and production errors

The ADF Performance Monitor logs errors with all relevant detail information. This information helps to discover, analyze, reproduce and resolve errors that happen frequently on test and production environments. Detailed information like exception message, timestamp, user ID, button/link clicked on, application server URI, and session is important to get insight into the errors and to resolve them. Additionally, the ADF developer can view the error stacktrace and ADF request callstack – allowing the developer to quickly troubleshoot these errors. In this example 42 errors have been collected during the selected time range (week) – for example errors like JboExceptions, SQLExceptions, NullPointerExceptions, ControllerExceptions, SQLIntegrityConstraintViolationExceptions, TxnValExceptions, e.g.

overview_errors2

Error Stacktraces

Developers can drill down to these errors, their type, severity and messages. The stacktrace can be viewed to analyze the root cause of the error – in this case a java.sql.SQLIntegrityConstraintViolationException:

stacktrace

Also the ADF request call stack can be viewed to understand more of the errors root cause. We can see that in this case just before the error occurred a PLSQL procedure was called that seems to be the cause: pagf001_api.maak_ctt_specifiek:

callstack

The ADF Performance Monitor logs errors at several extension points – one is with a custom DCErrorHandler:

MetricsErrorHandlerImpl

More information

More details are available on the AMIS site.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Performance Monitor: Troubleshooting Test and Production Errors appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/04/27/adf-performance-monitor-troubleshooting-test-and-production-errors/feed/ 0
Troubleshooting ADF ViewObject Range Paging Issues https://technology.amis.nl/2014/04/15/troubleshooting-adf-viewobject-range-paging-issues/ https://technology.amis.nl/2014/04/15/troubleshooting-adf-viewobject-range-paging-issues/#comments Tue, 15 Apr 2014 06:17:37 +0000 http://technology.amis.nl/?p=27430 Share this on .. ADF BC ViewObjects provide a very valuable mechanism to page through large data sets so that a user can navigate to a specific page in the results. Range Paging fetches and caches only the current page of rows in the ViewObject row cache (at the cost of another query execution) to [...]

The post Troubleshooting ADF ViewObject Range Paging Issues appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

ADF BC ViewObjects provide a very valuable mechanism to page through large data sets so that a user can navigate to a specific page in the results. Range Paging fetches and caches only the current page of rows in the ViewObject row cache (at the cost of another query execution) to retrieve each page of data. Range paging is very performing when your ViewObject has access to (hundreds of) thousands of database rows, and if you want to avoid JVM memory overconsumption. In my current project I ran into two severe performance problems that I will discuss in this blog. 

Issue one: Range Paging generates a SQL hint that can be very inefficient

The main search screen of our application uses ViewObject Range Paging. Extensive tuning and testing by our database experts proved that the query was extremely performing in the database when the concept of range paging was used (we only query around 40 – 50 rows each time). On our development environment everything worked fine. We always do performance analysis and regression analysis after new patches/releases to our test/acceptation environment. To our surprise, after a new release we detected a very slow ViewObject query and a very slow ‘SELECT COUNT(1)’ query in the ADF Performance Monitor, that was generated by our ViewObject with Range Paging. These queries correspond to the ViewObject methods executeQueryForCollection and getQueryHitCount():

getQueryHitCount2

After analyzing, we noticed that the ADF framework adds a hint to the ViewObject SQL:  /* FIRST_ROWS */

see_page_9_range_paging2

and this is exactly the problem in our case. First of all, the hint performs better when the range size (50) would be added to the SQL that we configured on our ViewObject:    /* FIRST_ROWS (50) */

range_range_paging

But in our case (to my own surprise) without the added SQL hint, the query is much faster: 100 milliseconds instead of 20 seconds! Our database expert explained that this was due to the execution plan that was chosen by the database. We searched and found a way to prune the SQL hint out of our query. The regex pattern for an SQL hint can be:

private Pattern pattern = Pattern.compile("/\\*\\+.*?\\*/", Pattern.DOTALL);

and by overriding the ViewObject method buildQuery() we can replace the hint with an empty string:

buildQuery

In this way the query performs really well – under 100 milliseconds.

Issue two: the SELECT COUNT(1) can be very slow

Frequently a ‘SELECT COUNT(1)’ query is executed to manage the number of rows displayed in a table, tree or treetable. When ViewObject Range paging is used, the framework automatically executes this query because it needs this information to manage the user scrolling up and down the table. In some cases this query can be very expensive and troublesome. In some case a RowCountThreshold at the iterator can be useful to avoid a full table scan:

rowcountthreshold

But in our case we had to create a dedicated ViewObject with a different, more efficient query to count the number of selected rows. We created a method on the ApplicationModule that executes this ‘CounterViewObject’. Now, the original ViewObject calls this method instead of the standard ‘SELECT COUNT(1)’ query. We do this in the overridden method getQueryHitCount():

getQueryHitCopunt_override

And in the counter method on the ApplicationModule the ‘CounterViewObject’ is executed:

executeQuerySearchShipmentsHitCount
In this way we could solve our performance issues with ViewObject Range Paging; now we have a very performing search screen with Range Paging:

searchscreen

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post Troubleshooting ADF ViewObject Range Paging Issues appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/04/15/troubleshooting-adf-viewobject-range-paging-issues/feed/ 5
ADF Runtime Diagnostics: Instrumenting your ADF Application – Part 2 https://technology.amis.nl/2014/04/01/adf-runtime-diagnostics-instrumenting-your-adf-application-part-2/ https://technology.amis.nl/2014/04/01/adf-runtime-diagnostics-instrumenting-your-adf-application-part-2/#comments Tue, 01 Apr 2014 05:38:04 +0000 http://technology.amis.nl/?p=27249 Share this on .. In a series of blog articles I show how you can instrument your ADF Application key actions. Instrumenting gives visibility and insight of what is happening inside the ADF application and in the ADF framework (what methods and queries are executed, when and how often). These runtime diagnostics can be very effective in identifying [...]

The post ADF Runtime Diagnostics: Instrumenting your ADF Application – Part 2 appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

In a series of blog articles I show how you can instrument your ADF Application key actions. Instrumenting gives visibility and insight of what is happening inside the ADF application and in the ADF framework (what methods and queries are executed, when and how often). These runtime diagnostics can be very effective in identifying and solving performance issues. 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. Part one was about instrumenting the ADF ViewObject. In this blog, part two, I will discuss instrumenting the ADF BC ApplicationModule.

ADF BC framework extension classes

As discussed in part one, you can instrument your ADF application with the use of ADF BC framework extension classes and overriding specific methods to measure important key actions inside the ADF framework. For an ADF BC ApplicationModule you can create a metrics ApplicationModule (for example called MetricsApplicationModuleImpl) that extends from oracle.jbo.server.ApplicationModuleImpl. Your project base class can extend from this MetricsApplicationModuleImpl:

MetricsApplicationModuleImpl

You can look at the ApplicationModuleImpl API doc for important and interesting methods to monitor.

Monitor ApplicationModule activation and passivation

As you know, ApplicationModule pooling enables multiple users to share several application module instances. It involves saving and retrieving session state data from the database, file, or Java memory. This mechanism is provided to make the application scalable and becomes very important under high load with many concurrent users. The default values can be very inefficient and may cause many unneeded passivations and activations. A quick and simple way to monitor passivations in ADF is to override the ApplicationModule method passivateState() in your metrics base class:

passivateState2

And to monitor activations override the ApplicationModule method activateState() in your metrics base class:

activateState2

In this way you can monitor which ApplicationModules are activated/passivated, their activation/passivation time, when and how often it is executed. Run your ADF application with -Djbo.ampool.doampooling=false to test this:

Djboampooldoampooling_is_false

Logging JDevelopers console log:

jdev_console

You might detect very frequent and long running activations and passivations. With this information you can experiment en test with ApplicationModule pooling parameters. It is especially useful to monitor this during load tests to find your most optimal ApplicationModule pooling parameter settings. In most cases, unfortunately, the default values are not the most optimal values. Carefully read the documentation in the ADF Fusion developers Guide (Ch. 44 of the 11gR2) for more information about these parameter settings.

Other interesting ApplicationModule pooling methods are passivateStateForUndo and activateStateForUndo.

Monitor ApplicationModule creation time & database connecting time

We can configure a custom DefaultConnectionStrategy class to measure ApplicationModule creation time and database connecting time. Our custom class must extend oracle.jbo.common.ampool.DefaultConnectionStrategy. In the same way as we did before, we can measure the creation and connect time.

AM_create_connect

Configuration on the ApplicationModule:

config_on_am

in JDevelopers console log:

jdev_console_am_create_connect

These methods are also interesting to monitor during a load test. For example, the connect() method could run very long when there are not enough database connections available, and it needs to wait for one. The next step could be to increase the maximum capacity in the datasource connection pool. Or to decrease the number of root ApplicationModules (and the number of database connections).

Monitor PLSQL calls

In the same way as described before you can instrument your PLSQL calls executed from your ApplicationModule. Frequently utility methods on the ApplicationModule are created for this purpose and they can be instrumented. You can log the execution time, the PLSQL statement, the ApplicationModule instance name, the IN and OUT parameters, e.g.

ADF Performance Monitor

The ADF Performance Monitor uses (amongst others) the extension points and methods described in this blog (and part one) to measure and record performance. It collects not only execution time but many additional metrics like ApplicationModule definition name, usage name, instance id, for which ViewObject data are being activated/passivated during an activation/passivation, e.g. . For every HTTP request a so called ‘ADF call stack’ is printed. These are the methods that we have overridden in our metrics class and other extension points in the ADF framework. The runtime diagnostics are available in JDeveloper and in a test/production environment. 

In the image below an example of a long running ApplicationModule activation of 22048 milliseconds (usage name HRService). 

activateState_PM2

As we can see, the slow activation is caused by activating the transient ViewObject attributes of HRService.LocationsViewRO in activateTransients(). We can see the value of instrumenting our ADF application and monitoring – now we can do something about the slow activation. For example to uncheck the  ‘Passivate State – Including All Transient Values’ checkbox at the ViewObject tuning section for HRService.LocationsViewRO.

Shown below is an example of a long running ApplicationModule passivation of 3796 milliseconds (usage name of HRService). This is caused by the same ViewObject, that passivates its transient attributes (HRService.LocationsViewRO):

passivateState_PM2

An example of a long running PLSQL statement and an ApplicationModule connect():

plsql_and _connect

Worst ApplicationModule activations & passivations overview

In the ADF BC overview (filtered on ApplicationModule pooling) the ApplicationModule pooling performance can be analyzed. This overview gives more insight in the effect of these parameter settings (how often passivations and activations happen, how long their AVG and total execution time is). On each ApplicationModule activation/passivation can be drilled down, to see the ADF request call stacks. Dev and QA teams can research and experiment with these parameter settings on test environments during load tests and evaluate the performance results in the monitor. They can determine the most optimal ApplicationModule pooling parameter settings for their situation. Operation teams can monitor the ApplicationModule pooling behavior in production.

am_pooling_overview

Total time of worst ApplicationModule activations & passivations

The performance impact of frequent invoked activations and passivations can be much higher than those that occur only a few times but are very slow on average. It is important to know which activations/passivations have the biggest impact on the resources of your ADF application. In this overview the x-as shows the AVG execution time (seconds) and the y-as shows the occurrences. The size of the bubble is total time (AVG execution time * occurrences).

am_pooling_overview_bubble

Occurrences overview

The occurrences overview shows how often activations and passivations are executed:

am_pooling_overview_occurences

We can see that PjtShowPaga001AM.passivateState, PjtShowPaga001AM.activateState and Pagd001AM.passivateState are executed very frequently. If we don’t want this behavior, we can adjust the pooling parameter settings.

More information about the ADF Performance Monitor is available on the AMIS site.

 

 

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Runtime Diagnostics: Instrumenting your ADF Application – Part 2 appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/04/01/adf-runtime-diagnostics-instrumenting-your-adf-application-part-2/feed/ 0
ADF Runtime Diagnostics: Instrumenting your ADF Application – Part 1 https://technology.amis.nl/2014/03/11/adf-performance-tuning-instrumenting-your-adf-application-part-1/ https://technology.amis.nl/2014/03/11/adf-performance-tuning-instrumenting-your-adf-application-part-1/#comments Tue, 11 Mar 2014 00:18:50 +0000 http://technology.amis.nl/?p=26707 Share this on .. In a series of blog articles I will show how you can instrument your ADF Application key actions. Instrumenting gives visibility and insight of what is happening inside the ADF application and in the ADF framework (what methods and queries are executed, when and how often). These runtime diagnostics can be very effective in [...]

The post ADF Runtime Diagnostics: Instrumenting your ADF Application – Part 1 appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

In a series of blog articles I will show how you can instrument your ADF Application key actions. Instrumenting gives visibility and insight of what is happening inside the ADF application and in the ADF framework (what methods and queries are executed, when and how often). These runtime diagnostics can be very effective in identifying and solving performance issues. 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. In this blog, part one,  I will discuss instrumenting the ADF BC ViewObject. In part 2 the ApplicationModuleImpl is discussed.

ADF BC framework extension classes

You can instrument your ADF application with the use of ADF BC framework extension classes and overriding specific methods to measure important key actions inside the ADF framework. You can use your project base classes or create a dedicated metrics package with extension classes for performance analysis and tuning. For an ADF BC ViewObject you could create a metrics ViewObject (for example called MetricsViewObject) that extends from oracle.jbo.server.ViewObjectImpl. Your project base class can extend from this MetricsViewObject:

vo_extension_class

Monitor slow queries

You can measure exactly – like a stopwatch – the execution time of a Java method by retrieving the current nano time just before and immediately after the method execution by calling System.nanoTime(). System.currentTimeMillis() can be a few milliseconds inaccurate.  See the API doc of System.nanoTime() and System.currentTimeMillis().

long startTime = System.nanoTime(); 
//method being measured ...
long estimatedTime = (System.nanoTime() - startTime) / 1000000;

 

You can look at the ViewObjectImpl API doc for important methods to monitor.

A quick and simple way to monitor executed database queries in ADF is to override the ViewObject method executeQueryForCollection() in your metrics base class. In this way you can monitor which ViewObject queries are executed, their execution time, when and how often. You might detect redundant or unexpected ViewObject queries. With this method you can monitor all queries including queries from ViewAccessors, programmatic ViewObjects, detail queries from ViewLinks, e.g. ).

executeQueryForCollection

A ViewObject usage name that contains ‘_LOCAL_VIEW_USAGE‘ is a generated ViewAccessor name and is also just a ViewObject query. In JDevelopers console log:

output_jdev_console

The executeQueryForCollection() method of the ADF Performance Monitor is shown in the image below. The monitor only measures when the monitor is turned on. It has a start-point, and an endpoint in a finally block:

metrics_executequeryforcollection

The metrics are collected in a separate object called MetricsVoExecution. Extra runtime metrics are collected like bind variable name and values, ViewObject definition name, fetched rows, e.g. to make the metrics even more useful. The execution time is measured in the superclass call super().

metrics_viewobject_execution

Monitor slow select count query

Frequently ‘SELECT COUNT (1)’ queries are executed by the ADF framework to count the number of rows that would be returned if the View Object is executed with the current query (mainly for tables and trees). This query could be a potential bottleneck if it takes very long to execute, and for this reason the method getQueryHitCount() is useful to monitor:

HR_getQueryHitCount

Monitor passivating and activating ViewObject transients

In the same way you can override the activateTransients() and passivateTransients() method.  activateTransients() restores attribute values from a ViewObject (if there are transient attributes passivated) and passivateTransients() stores attribute values. Both methods can potentially take a lot of time if the Passivate State – Including All Transient Values checkbox is checked at the ViewObject tuning section:

passivateAllactivatingAndpassivating

Our performance logging in JDevelopers console log can look like this (I put a delay in the query of the EmployeesView ViewObject of 15 seconds) looks like this:

jdev_console_log2

You might want to look at the ViewObject API to override other interesting methods as well. You can consider to only log metrics when the execution time passes a configurable threshold.

Monitor fetched rows from the database

In my previous blog about detecting a high ADF BC memory consumption I explained how you can instrument and measure how many rows are fetched from the database, and how many ViewObject rows are created and cached. The most important method to override is createRowFromResultSet() and counting them in the MetricsViewObjectImpl or BaseViewObjectImpl. Reset the counter before a query is executed (again).

BaseViewObjectImpl2

A high load can now be detected in JDevelopers console log. You might want to not log every single row that is fetched but only when you detect a high load.

ADF Performance Monitor

The ADF Performance Monitor uses (amongst others) the extension points and methods described in this blog to measure and record performance. It collects not only execution time but many additional metrics like  bind variable name and values, ViewObject definition name, fetched rows, time spent fetching database rows, e.g. . For every HTTP request a so called ‘ADF call stack’ is printed. These are the methods that we have overridden in our metrics class and other extension points in the ADF framework  (in the next parts I will discuss many of them). 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. ADF developers can switch the metrics logging on and off with the standard ADFLogger of Oracle. The logging of the ADF Performance Monitor in JDeveloper looks like this (for use in a development environment):

jdev_metricslogging_APM

Monitoring in production

The callstacks printed in JDeveloper are also available as runtime diagnostics in a production environment. In the image below an example is shown of a long running ViewObject query (method executeQueryForCollection() ) of 18033 milliseconds (usage name of HRService.EmployeesView1):

callstack3

A callstack with an example of  a long running activateTransients() and passivateTransients()  – of HRService.LocationViewRO :

adf_callstack_activate_passivate_transients

In test and production environments, the ADF request call stacks of the ADF Performance Monitor provides similar functionality as the runtime diagnostics 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).

More information about the ADF Performance Monitor is available  on the the AMIS site  

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Runtime Diagnostics: Instrumenting your ADF Application – Part 1 appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/03/11/adf-performance-tuning-instrumenting-your-adf-application-part-1/feed/ 0
ADF Performance Tuning: Tips on How to Limit ADF BC Memory Consumption https://technology.amis.nl/2014/02/18/adf-performance-tuning-tips-on-how-to-limit-adf-bc-memory-consumption/ https://technology.amis.nl/2014/02/18/adf-performance-tuning-tips-on-how-to-limit-adf-bc-memory-consumption/#comments Tue, 18 Feb 2014 00:57:33 +0000 http://technology.amis.nl/?p=26049 Share this on .. This blog contains tips and tricks on to how limit the JVM memory consumption of ADF applications. Like other web applications, Oracle ADF applications potentially use a lot of JVM memory. Many times, the root cause of a high memory usage is that application data retrieved from the database into memory is [...]

The post ADF Performance Tuning: Tips on How to Limit ADF BC Memory Consumption appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

This blog contains tips and tricks on to how limit the JVM memory consumption of ADF applications. Like other web applications, Oracle ADF applications potentially use a lot of JVM memory. Many times, the root cause of a high memory usage is that application data retrieved from the database into memory is not properly bounded; too many rows are fetched and held in ADF BC memory. This can lead to memory over-consumption, very long running JVM garbage collections, a freeze of all current requests or even OutOfMemoryErrors. To make matters worse, these rows and their attributes are frequently passivated and activated for an unnecessary long period of time. The solution to this problem can be found in reducing the size of sessions by decreasing of the amount of data loaded and held in the session. With a low memory consumption, a more responsive, stable and scalable ADF application can be delivered.

Long JVM garbage collections

A ‘happy JVM’ is important. If garbage collections are running very long (for example more than 30 seconds), this is often an indication of a problem – such as a freeze of all current requests because the JVM cannot clear enough memory. In the image below an example is shown of very long running garbage collections (red line). The heap space (blue) over time evolves more into a horizontal line than the saw-tooth shaped line a healthy JVM would be characterized by. In this case an OutOfMemoryError occurred and the server needed to be restarted. This should be a trigger to investigate whether the JVM heap space is set too low or that the ADF application consumes too much memory.

long_running_jvm_garbage_collection

Root cause of memory overload

When the JVM heap space is set at a reasonable value, the root cause of memory over-consumption is often that the ADF application fetches far too many rows (and too many attributes – I will address this subject in another blog).

overload_vuilnisauto

This can happen when the ViewObject SQL query potentially has access to thousands or even hundreds of thousands of database rows and it does not have (or not enough) restricting bind variables (or when no ViewCriteria is applied).

Further (one or more):

  • An af:table, af:treeTable, af:tree component is used in a page and the underlying ViewObject’s Access Mode is Scrollable (this is the default value at the ViewObject tuning section)

scrolling_down_locations

  • The iterators RangeSize property (in the PageDefinition file) is set to -1

rangesize_minus_one

  • The ViewObject fetchSize is set to All Rows – (All at Once)

fetchsize_all_at_once

  • A ViewObject is only used for inserting new records (and its fetchsize is still set at the default value All Rows – (As Needed) – it can still execute its SQL query (and unintentionally fetch all database rows that are accessible)

fetchsize_default_as_needed

  • Iterating in Java through all ViewObject rows

Limiting rows fetched in ADF BC memory

Range paging

ADF ViewObjects provide a mechanism to page through large data sets so that a user can navigate to a specific page in the results. Range Paging fetches and caches only the current page of rows in the ViewObject row cache (at the cost of another query execution) to retrieve each page of data. Range paging is not beneficial for small data sets where it is better to have all fetched rows in the ViewObject row cache. With Range paging you can say: “I would like to see page 9 of the search results (and 10 per page)”:

  • R = Range size (rows per page)
  • P = Page number of the results

see_page_9_range_paging

You can set the ViewObject Access Mode to Range paging in the ViewObject tuning section:

vo_tuning_section_range_paging

Maximum fetchsize on ViewObject

It is very important to limit the impact of non-selective queries that may return thousands of rows is setting a maximum fetchsize on the ViewObject instance. Recommend values are:

  • Table-layout:    Only up to row number:  Set this to ± 250 rows and set a proper fetchSize (or use Range Paging)
  • Form-layout:    At Most One Row (for dedicated ‘single row’ ViewObjects, when the ViewObject is being used only in the context of a single row (like the form part of a table/form layout). When a table row of a table/form layout is selected or clicked on, the form layout ViewObject is queried  with its ID value as bind parameter (for example with the executeWithParams operation). For table/form layout it is a good practice to create two separate fysical ViewObjects for table and form, especially when the table can fetch more than ± 250 rows database rows.
  • Insert-layout:  No Rows (for Insert-only View Objects, when you know the Viewobject is being used only in insert mode)

max_fetchsize

An excellent way to prevent loading too much (database) rows is to set a global maximum fetchsize. You can set a global Row Fetch Limit in ADF META-INF/adf-config.xml:

global_max_fetchsize

If you do want to set a higher or smaller maximum fetchsize for individual ViewObject instances, you can still set a different value at the tuning section of an instance and override the global threshold. It is recommended to think carefully for each ViewObject what the best value is.

Extra bind variables on ViewObject

If your ViewObject fetches/loads a large dataset, you can limit it with extra bind parameters (or extra ViewCriteria). For example, on a search screen end-users must fill in extra mandatory search fields that correspond to extra bind parameters, to make the database query resultset smaller.

Alternatively, before you execute the ViewObject query of an import (search) screen that has access to thousands of rows you can first execute a select COUNT that gets the number of rows returned by the query.

found_too_many_rows_message

If the number of rows exceeds a certain threshold (for example 250 rows), a message can be shown to the end user that too many results are found and that more refined, specific search terms or date restrictions are required. Only if the number of found results does not exceed the threshold, the query is executed, the database rows are fetched/loaded and the user gets the results.

Read-only ViewObjects

If a ViewObject does not have to insert or update data, use a more memory friendly read-only ViewObject;

  • Non updatable EO based ViewObject (deselect updatable in the ViewObject editor)
  • Expert-mode read-only ViewObject

ApplicationModule lazy loading

It is recommended to defer the runtime instantiation of ViewObject and nested ApplicationModule instances until the time they are used. You can set this in the ApplicationModule tuning section:

AM_lazy_loading

Shared ApplicationModule

Use a shared ApplicationModule to group view instances when you want to reuse lists of static data across the application.

shared_AM

ApplicationModule Pooling

When a ViewObject is properly tuned and limited in its fetching, only the rows really needed are being kept in memory. This is very important for performance and to keep the memory low. This will also make ApplicationModule pooling activations and passivations much faster. ApplicationModule pooling parameter settings are also very important for performance, I will address this in another blog.

Detecting an overload of ViewObject rows

One of the new features of the ADF Performance Monitor is a kind of ADF BC memory recorder and analyzer. It detects and warns when too many ViewObject (database) rows are being fetched/loaded into memory. Also, for a selected time range (month, week, day, e.g.), the tool gives aggregated overviews for each ViewObject instance how many rows have been fetched/loaded into ADF BC memory (ViewObject row cache or EntityCache). ViewObjects that frequently fetch hundreds or thousands of rows – and waste memory – can be detected. Also individual high fetches/loads can be analysed.

ADFBC_memory_scan_total

With this information, ViewObject instances that frequently fetch too many database rows can be addressed by the suggestions written in this blog; adding extra bind parameters, setting a (better) maximum fetchsize or using Range Paging.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Performance Tuning: Tips on How to Limit ADF BC Memory Consumption appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/02/18/adf-performance-tuning-tips-on-how-to-limit-adf-bc-memory-consumption/feed/ 0
ADF Performance Monitor: Customer Case Video https://technology.amis.nl/2014/02/10/adf-performance-monitor-customer-case-video/ https://technology.amis.nl/2014/02/10/adf-performance-monitor-customer-case-video/#comments Sun, 09 Feb 2014 23:23:46 +0000 http://technology.amis.nl/?p=25978 Share this on .. The ADF Performance Monitor is designed for measuring, analyzing, tuning, 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 [...]

The post ADF Performance Monitor: Customer Case Video appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The ADF Performance Monitor is designed for measuring, analyzing, tuning, 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.

Recently an overview video, a whitepaper and a blog on its ADF BC memory analyzer was published. This blog publishes a customer case video of the Dutch Ministry of Justice.

Customer case video (4 minutes)

This video shows how the ADF Performance Monitor helped the Dutch Ministry of Justice to solve their performance problems. The primary information system for the Dutch judiciary is replaced with a new system based on Oracle ADF. Some facts about this project:

  • Very large ADF application (1000+ ViewObjects, 15+ ApplicationModules)
  • 15+ developers
  • 5000+ end-users
  • 100+ concurrent requests
  • production environment: 4 Weblogic nodes with each 16 GB JVM memory`
  • Frequently response times over 20 seconds
  • Many times long running JVM garbage collections over 60 seconds

video_customer_case2

More information

More details are available on the AMIS site.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Performance Monitor: Customer Case Video appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/02/10/adf-performance-monitor-customer-case-video/feed/ 0
ADF Performance Monitor: Detecting and Analyzing a High ADF BC Memory Consumption https://technology.amis.nl/2014/02/03/adf-performance-monitor-detecting-and-analyzing-a-high-adf-bc-memory-consumption/ https://technology.amis.nl/2014/02/03/adf-performance-monitor-detecting-and-analyzing-a-high-adf-bc-memory-consumption/#comments Sun, 02 Feb 2014 23:27:32 +0000 http://technology.amis.nl/?p=26187 Share this on .. Like other web applications, Oracle ADF applications potentially use a lot of JVM memory. Many times, the root cause of a high memory usage is that application data retrieved from the database into memory is not properly limited; hundreds or thousands of rows (with too many attributes) are fetched and held [...]

The post ADF Performance Monitor: Detecting and Analyzing a High ADF BC Memory Consumption appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Like other web applications, Oracle ADF applications potentially use a lot of JVM memory. Many times, the root cause of a high memory usage is that application data retrieved from the database into memory is not properly limited; hundreds or thousands of rows (with too many attributes) are fetched and held in ADF BC memory. This can lead to memory over-consumption, very long running JVM garbage collections, a freeze of all current requests or even OutOfMemoryErrors. To make matters worse, these rows and their attributes are frequently retained (passivated and activated) in the session for an unnecessary long period of time. The solution to this problem can be found in reducing the size of sessions by decreasing of the amount of data loaded and held in the session. With a low memory consumption, a more responsive, stable and scalable ADF application can be delivered.

This blog describes one of the new features of the ADF Performance Monitor; 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.

ADF BC memory load analyzer of the ADF Performance Monitor

For a selected time range (month, week, day, hour, 5 minute), the tool gives aggregated overviews for each ViewObject instance how many rows have been fetched/loaded into ADF BC memory (ViewObject row cache and entity cache). ViewObjects that frequently fetch hundreds or thousands of rows – and potentially waste memory – can be detected. Individual high fetches/loads can be further analyzed.

For each ViewObject, for a selected time range (month, week, day, e.g.), there are the following overviews:

  • The total (sum) of all the ViewObject rows (by ViewObject) that are created in ADF BC memory and fetched from the database. In this overview (screenshot below) ViewObject instances that frequently fetch too many database rows can be detected. The metrics of this example overview is coming from a test server. In this case we can see that ViewObject instance Pagg009ShowAM.GbsVslVO is fetching/retrieving by far the most rows – frequently thousands of database rows. We can see that from mid November 2013 to the end of January 2014 it fetched in total 184.000 database rows (and created 184.000 ViewRowImpl objects). And the highest fetch was 7000 rows in a single HTTP request. This should be a trigger for further investigation.

ADFBC_memory_scan_total

  • The maximum ViewObject rows (by ViewObject) that are fetched from the database and created (cached) in ADF BC memory in a single HTTP request. In general, to avoid memory over-consumption, very long running JVM garbage collections, a freeze of all current requests or even OutOfMemoryErrors, we should not allow ViewObjects to fetch and load more than ±500 rows. All ViewObject instances that are able to fetch and cache more than ±500 rows should be a candidate for further investigation. In this case (see image below) the same ViewObject instance Pagg009ShowAM.GbsVslVO has fetched the most rows of all ViewObjects in a single HTTP request: 7000 rows. The other ViewObjects that have fetched more than 500 rows should also be investigated.

ADFBC_memory_scan_max

With these two overviews, ViewObject instances that frequently fetch and load too many database rows can be addressed.

The tool can zoom in and analyze the individual high load (fetch) occurrences of a ViewObject (click on the ViewObject instance name). In the detail overview we can analyze when the high load occurrences happened and how many rows were fetched each time:

occurrences

We can drill down further to the call stack of the HTTP request. It can be useful to analyze, and find out more details about the circumstances of the high load like: What were the bind parameter values of the ViewObject query? Which ViewCriteria were applied (if one was applied)? Did it happen during ApplicationModule activation? Which taskflow was involved ?

callstack

With all this detail information, ViewObject instances that frequently waste ADF BC memory can be addressed. For example by adding extra bind parameters, setting a (better) maximum fetchsize or using Range Paging.

Detecting an overload of ViewObject rows

The metrics classes of the ADF Performance Monitor make use of extension points in the ADF framework in order to measure the time every action/step takes in a http request. It makes use of ADF BC framework extension classes. To measure how many rows are fetched from the database and how many ViewObject rows are created and cached, there are several possibilities:

  • Invoking the getFetchedRowCount() in the BaseViewObjectImpl after the fetch is complete:

                int fetched = viewObjectImpl.getFetchedRowCount();

  • Measuring the population of ViewRowImpl objects in the base BaseViewObjectImpl

BaseViewRowImpl

And counting them in the BaseViewRowImpl. Before a query is executed (again), you should reset the counter.  You can do this in the executeForCollection(), the method that is invoked before each database query.

BaseViewObjectImpl

  • Overriding the method createRowFromResultSet() and counting them in the BaseViewObjectImpl. This is how the ADF Performance Monitor keeps track of the number of fetched rows and number of ViewRowImpl objects created. Reset the counter before a query is executed (again):

BaseViewObjectImpl2

A high load can now be detected in JDevelopers console log. You might want to not log every single row that is fetched but only when you detect a high load.

large_fetch_jdev

More information

Recently an overview video and a whitepaper have been published. More details are available on the AMIS site.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Performance Monitor: Detecting and Analyzing a High ADF BC Memory Consumption appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/02/03/adf-performance-monitor-detecting-and-analyzing-a-high-adf-bc-memory-consumption/feed/ 1
ADF performance tuning: Whitepaper published on the ADF Performance Monitor https://technology.amis.nl/2014/01/21/adf-performance-tuning-whitepaper-published-on-the-adf-performance-monitor/ https://technology.amis.nl/2014/01/21/adf-performance-tuning-whitepaper-published-on-the-adf-performance-monitor/#comments Tue, 21 Jan 2014 00:00:16 +0000 http://technology.amis.nl/?p=25787 Share this on .. 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 [...]

The post ADF performance tuning: Whitepaper published on the ADF Performance Monitor appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

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.

History

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.

product_overview

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.

whitepaper_image2

Content of the whitepaper:

  • Executive overview
  • Introduction
  • 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
  • Configuration
  • Turn on/off at all times
  • Prerequisites
  • Monitored Events

Functionality

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) :

callstack3

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.

ADFBC_worst_executions5

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

More information is available on the the AMIS site.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF performance tuning: Whitepaper published on the ADF Performance Monitor appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/01/21/adf-performance-tuning-whitepaper-published-on-the-adf-performance-monitor/feed/ 0
ADF Performance Tuning: Improve Your Oracle ADF App Response Time by as Much as 70 Percent https://technology.amis.nl/2014/01/17/adf-performance-tuning-improve-your-oracle-adf-app-response-time-by-as-much-as-70-percent/ https://technology.amis.nl/2014/01/17/adf-performance-tuning-improve-your-oracle-adf-app-response-time-by-as-much-as-70-percent/#comments Fri, 17 Jan 2014 14:55:08 +0000 http://technology.amis.nl/?p=25726 Share this on .. Performance needs to be ingrained in your application – it cannot be added in during the last stages of development. In this video I discuss how you can optimize the performance of your Oracle ADF Fusion application, diagnose and solve typical performance problems, and build an efficient, responsive, scalable ADF application [...]

The post ADF Performance Tuning: Improve Your Oracle ADF App Response Time by as Much as 70 Percent appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Performance needs to be ingrained in your application – it cannot be added in during the last stages of development. In this video I discuss how you can optimize the performance of your Oracle ADF Fusion application, diagnose and solve typical performance problems, and build an efficient, responsive, scalable ADF application that circumvents common bad practices. This video was originally presented as part of the Oracle ACE Track during the Oracle Technology Network Virtual Developer Day event “Oracle ADF Development – Web, Mobile and Beyond.” Last week the video was published on OTNArchBeat (Oracle Architect Community Video Channel).

Video session of Oracle Virtual Developer Day (42 minutes)

Important: to watch in high quality, select HD quality (720p).

HDquality_select_in_youtube

Content

In the video I discuss several categories of things that are happening frequently too slowly, too often, too little, too soon and too big in ADF applications, and solutions.

Agenda of video session – things that are happening in ADF applications:

  • Too slowly (too slow ViewObject queries, EntitObject DML operations, ApplicationModule pooling passivations and activations)
  • Too often (too many (mini) queries, too many database round-trips, too many HTTP Requests, too many full HTTP Requests, too frequent ApplicationModule passivation & activation, unintentionally left iterators in PageDefs)
  • Too big (too much data in ADF BC memory, too big scope for managed beans, too much HTML to the browser, too much logging on)
  • Too soon (too soon executed taskflows, too soon instantiated ApplicationModules, ADF UI components that are loaded too soon (Immediate versus lazy))
  • Too little (too little Caching, too little JVM Heap size)

At AMIS we frequently use the ADF Performance Monitor to detect, analyze and help resolve the problems discussed in this video.

The PPT version of the video is available here (contains a lot of animations).

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF Performance Tuning: Improve Your Oracle ADF App Response Time by as Much as 70 Percent appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/01/17/adf-performance-tuning-improve-your-oracle-adf-app-response-time-by-as-much-as-70-percent/feed/ 0
ADF performance tuning: Overview Video published on the ADF Performance Monitor https://technology.amis.nl/2014/01/14/adf-performance-tuning-video-demo-published-on-the-adf-performance-monitor/ https://technology.amis.nl/2014/01/14/adf-performance-tuning-video-demo-published-on-the-adf-performance-monitor/#comments Tue, 14 Jan 2014 09:47:57 +0000 http://technology.amis.nl/?p=25543 Share this on .. A good performance is the key to the success of a web application. Oracle ADF applications are no exception to this rule. ADF performance tuning can be time intensive, costly and quite a challenge when performance issues require developers to delve deep into the inner workings of the ADF framework. The [...]

The post ADF performance tuning: Overview Video published on the ADF Performance Monitor appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

A good performance is the key to the success of a web application. Oracle ADF applications are no exception to this rule. ADF performance tuning can be time intensive, costly and quite a challenge when performance issues require developers to delve deep into the inner workings of the ADF framework.

The AMIS ADF Performance Monitor is an advanced tool specifically designed for measuring, analyzing, tuning, and checking the performance of Oracle ADF applications. The tool 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. This blog contains an overview video of the main features.

About the ADF Performance Monitor

The first version of this tool was already released in 2009 (ADF 10g). One year later (2010) the second version (ADF 11g) was released. Last years the monitor has been improved 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 and has been proven to be very useful. Read the quotes of ADF experts and managers.

New overview video published

video_pm_overview

if the video does not load, watch the video at youtube:

Oracle ADF applications and performance

ADF is a powerful, advanced and highly configurable framework that is very performing and scalable if the ADF developer chooses the right combination of parameter settings. However, web applications in general and ADF applications in particular have many pitfalls that can be circumvented by choosing the correct performance configuration parameter settings. In most cases, unfortunately, the default values are not the most optimal values.

Frequently even experienced ADF developers cannot pinpoint why an ADF application is slow. In this case information of what is happening behind the scenes would be very useful in order to get a better understanding of their ADF application.

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).

Development, QA and operation teams

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 ADF developers can diagnose and solve performance problems already in an early stage, make better (architecture) decisions and can build more responsive and scalable ADF applications. With the warnings and suggested solutions of the ADF Performance Monitor they can circumvent frequent performance problems, use best practices and deliver a higher quality. This will lead to an application that is more consistent and better to maintain. They can reduce the utilization of infrastructure, hardware and licenses. End-users will be more happy.

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.

Whitepaper

A whitepaper on the ADF Performance Monitor is available.

More information

More information is available on the the AMIS site  

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post ADF performance tuning: Overview Video published on the ADF Performance Monitor appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2014/01/14/adf-performance-tuning-video-demo-published-on-the-adf-performance-monitor/feed/ 0
JavaOne 2013: Java Mission Control https://technology.amis.nl/2013/10/06/javaone-2013-java-mission-control-2/ https://technology.amis.nl/2013/10/06/javaone-2013-java-mission-control-2/#comments Sun, 06 Oct 2013 18:49:09 +0000 http://technology.amis.nl/?p=24812 Share this on .. The convergence project between Oracle’s JVMs JRockit and Hotspot is making significant progress. Included in the latest Java 7 JDK update (‘7u40′) is a new powerful monitor tool: Java Mission Control (JMC). JMC is a production time tool that has its roots in the JRockit JVM tooling. It is located in the bin [...]

The post JavaOne 2013: Java Mission Control appeared first on AMIS Oracle and Java Blog.

]]>
Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The convergence project between Oracle’s JVMs JRockit and Hotspot is making significant progress. Included in the latest Java 7 JDK update (‘7u40′) is a new powerful monitor tool: Java Mission Control (JMC). JMC is a production time tool that has its roots in the JRockit JVM tooling. It is located in the bin folder of your 7u40 JDK. At JavaOne I attended some interesting sessions by Marcus Hirt (Oracle) on this new Java Mission Control. In this article I will describe an introduction based on my session notes to get you started and links to further explore JMC.

Flight Recorder1

Introduction

JMC is intended to be the new tool for monitoring, managing, diagnosing, and profiling your Java applications. It is built into the JVM. It is meant for production use but it can of course be very valuable in any environment (development, test). It gives a basic monitoring, profiling and diagnostics information. Oracle claims that it has a very low overhead of less than 2%.

Oracle’s JVMs JRockit and Hotspot convergence

The JRockit and HotSpot features are currently being merged into one JVM. The intention with the merge is to make a ‘best of breed’ JVM. This is a project that is still going on but now with JDK release 7u40 it has reached a very big milestone; Mission Control for Hotspot. It is intended as an 1.0 release but released as version 5.2.0. Delivered in the JDK 7u40 release are:

  • JMX Console – for monitoring running Java processes in real time and monitoring of a few select key indicators
  • Java Flight Recorder – profiling of running production systems (like a data flight recorder  in an aircraft) with minimal overhead

Memleak, a very useful JRockit heap-analyser, is unfortunately not available yet in JMC but will be in the future.

JMC installation

-You can download the 7u40 JDK or higher here:

-To enable access to the Flight Recorder four Java parameters must be set (this is not yet dynamically enabled like in JRockit). In WebLogic  for example you can set the parameters in  <your path to WLS Domain>/bin/startWebLogic.cmd:

  • -XX:+UnlockCommercialFeatures
  • -XX:+FlightRecorder
  • -Dcom.sun.management.jmxremote.authenticate=false
  • -Dcom.sun.management.jmxremote.ssl=false

WebLogic java prop

– Double-click on the launcher in bin folder to start JMC:

start JMC

JMX Console

You can start a JMX console by a right mouse click on a JVM:

start JMX console

The JMX Console is a tool for monitoring and managing multiple JVMs. It captures and presents basic live performance data about garbage collection pauses, memory and CPU usage, as well as performance information from any (custom) JMX MBeans deployed in the JDK MBean server.

JMX Console1

Java Flight Recorder (JFR)

The Java Flight Recorder (JFR) is in my opinion a very useful and the most powerful tool of JMC. With JFR operation teams and developers have a new tool to diagnose production issues. JFR provides a way to collect events from a Java application, from the OS layer, the JVM, the CPU, and all the way up to the Java application. The collected events include JVM memory, garbage collections, thread latency, events such as sleep, wait, lock contention, and method profiling. The performance metrics are written to the disk and analysis can be done afterward if problems have occurred. Because of the low performance overhead, it is save to put JFR always on in production environments.

Hot packages and classes:

Flight Recorder3 hot packages classes

Java Mission Control Future

Oracle is currently working on version 5.3.0 of JMC. This version will be released with JDK 8 and a later 7 update. It will include an improved JMX Console (Remote Diagnostic Commands and more), improved content type handling and formatting. Oracle is also working on version 6.0.0 which includes an automatic analysis of JFR recordings.

Experimental plugins

JOverflow is one of the many promising, experimental (and not supported) plugins. JOverflow is for analyzing heap waste (empty/sparse collections)

JMC as external tool in JDeveloper12C

-If you want to play with JMC in JDeveloper 12C, you can add JMC as an external tool to JDeveloper and use it directly from JDeveloper’s menu. The current JDeveloper version (12.1.2) ships with JDK version 1.7.0_15 and includes a limited previous version of JMC ( 5.1). To make JMC 5.2 available, you need to change the JDK JDeveloper uses. Copy and paste your 7u40 JDK in your oracle_common directory: Middleware1212\Oracle_Home\oracle_common and rename the folder to jdk (but first rename your old jdk folder)

jdk7u40 in oracle_common pasted

– Go to the JDeveloper menu, Tools and external Tools:

JMC as tool in JDev

Now JMC is directly startable from JDevelopers menu.

Links

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The post JavaOne 2013: Java Mission Control appeared first on AMIS Oracle and Java Blog.

]]>
https://technology.amis.nl/2013/10/06/javaone-2013-java-mission-control-2/feed/ 1