Performance issues in oracle ADF. How to detect performance issues in ADF Applications?

Oracle ADF is a very exhaustive framework that provides so many inbuilt functionalities to ease the work of the developer and help the developer in building applications quickly. ADF was built to support large Enterprise level Applications. But with so many functionalities sometimes due to large data or improper implementation of certain business functions, comes the issues related to the performance of the Applications.

ADF is fast!! If your ADF Application is slow, that eventually is due to development mistakes.

This blog post is related to ADF Performance issues that we face in applications. The most important challenge is to identify the exact issue and resolve that issue. Here are a few issues which I have found out during development as ADF Developer.

Reasons for performance issues in Oracle ADF applications

1. Long-running view object Query.

This can be the main reason for the slow performance of the ADF application. First, the Query needs to be identified which is causing the problem. How to identify the query?? I have posted a very detailed answer in this post. The performance-related issue in oracle ADF? How to Identify long-running queries of View Object?

2. ViewObject loading a huge number of records in the memory. 

This happening mostly due to the unintentional loading of huge no. of rows in the memory. How to identify the root cause. In this post, I have looked into this issue in detail. ADF ViewObject loading a huge number of records in the memory? Why? How this can be stopped?

3. Repeated execution of view accessors.

View accessors are the source for a Lov in a view object. There is a property that defines if the view accessor will be executed for all the rows in the view object or not. If the LOV values will remain the same for all the rows of the view object then this needs to set false. In the other case, this needs to be set to false.

4. Repeated execution of database functions in attribute getters in rowImpl classes.

The getters are called every time a value is called. The getters are called each and every time a values is called and if some calculating logic is written then it will be called many times which will eventually reduce the performance of the application.

5. Slow running database call, like database function or procedure, etc.

A database function or procedure that is being called is not optimized and taking much time to execute. If this is the case then optimization needs to be done at database level.

6. Unintentional use of "ignore case" clause in view criteria.

Ignore case is used to ignore the case of values in where clause. When we use the upper clause the sql query is like 

 ( (UPPER(Employees.FIRST_NAME) = UPPER(:bindFirstNm) ) ) 

 as we know that the upper clause is slower than normal where clause. Sometimes if this is used unintentionally this can be a cause for the slow query.

7. Improper use of LOV type.

There are so many different types of LOV's in ADF and each has a different purpose. If the LOV is used properly for the business scenario for which it is applicable, then it can lead to different issues which can be problematic. For Example, if we use single selection LOV for a Larg no. of records then it can cause the Application to load slow. I have a detailed post where I have explained this in detail. What happens when we use the wrong type of a LOV??

 

8. Improper view object tuning.

View Objects are used to fetch records from the database. View objects by default tuned for optimal usage. But in some business cases if we are required to play with a large no. of rows of a view object. So the rows need to be loaded in the memory intentionally. In this case, we can use view object tuning to fetch the rows into memory in minimum time. This is not one fit for all solutions. But this will work well. We have some tuning parameters of view object defined in view object tuning section of a view object. 

I have discussed these parameters in detail in an old post of mine. https://adfjavacodes.blogspot.com/2014/04/adf-scrolling-in-table-with-large-data.html

9. Improper implementation of a use case.

This is the obvious reason in most for the performance-related issues in ADF. This case is best explained in the blog of Andrej https://andrejusb.blogspot.com/2017/11/adf-performance-story-this-time.html



If you have any queries related to the above blog post, please feel free to ask. :)