We simply do not care at the performance issues it might create later in system testing or in production environment with real life load. I am not a guru of performance tuning but here is a little I learned from my experience:
1. Carefully investigate each and every instance you added in the Application module of your view objects. Go to the tunning tab and there set the batch size equals to 1 more than the expected number of rows the VO is expected to get from DB in most of the cases. This will save un-necessary db trips. So, say a VO instance is supposed to retrieve 20 rows from db then change the batch size to 21. By default it is 1.
2. Iterating over View objects is fairly easy and we easily get into the habit of copy paste the code to iterate over the View object to look for some particular row. Avoid that. Where ever possible have a view criteria with bind variables and use it in your code to fetch the desired row.
3. One of the most neglected area is executables sometimes left in pageDefinition files and un-used. During development we try various options when something does not work and forget to remove the dead code. So, those executables run at the page load time automatically and slow down the page load time even it does not have any other side-effects on the functionality of your app. So, remember to analyze bindings and executable in your pageDef and cleanup if needed.
4 comments:
Your right about point 3. But shouldn't there be some kind of 'dead code'-tool, to help you with the task of removing the dead code?
I've seen this in other tools like pl/sql-developer by alround automations. http://www.allroundautomations.com/plsqldev.html
(Im not'affiliated )
Well it is not always possible to do a automated dead code cleanup. The reason is sometimes you create iterator bindings on you pageDef file and use them programmatically in a managed bean.
So, there may not be an easy way to find something absolute dead to remove it.
Yes a tool suggesting what is not used directly on the page as possible candidate could be there.
Main performance problem in ADF is default SQL query execution.
1. When opening page, it sending SQL without WHERE clause to DB. Solution for this is to use Range Paging on View Obect - but in current build its not working. As I know its fixed in internal Oracle build
2. When using LOV components, framework send series of duplicate selects to DB, sometimes with different Bind Variables. Its killing performance on 10000 row LOV tables. Again, solution for this is Range Paging, when it will be fixed.
Andrejus
Hello, after reading this awesome post i am as well happy to share my experience here with colleagues.
Post a Comment