Bc4j,dacf:[3.2.3] Searching for the performance boost switch

Question

As I mentioned in the thread http://technet.oracle.com:89/ubb/Forum2/HTML/008025.html
I am investigating the performance of an application.
Some new Information on this. I get some speedup by deactivating the locking. But the app is not really responsive. Paging down a grid takes about 4-6sec per page. Another test showed that there is no difference if I use one table or a join.
Now I made some JSP. These are running real fast. The normal pages load under 2sec.
So far I can see the problems seems to in the communication between the BC4J and the DACs.
Has anyone some optimization suggestion? (I use the generated frames and JSPs)
Bernd

Answer 1

Hi Bernd,
currently I try to speed up our application that is based on applets and DACFs in local deployment mode, too.
Here are my results and I would like to discuss my observations within this thread:
- Startup time (login) about 30 sec. is normal and can't be improved programmatically.
- Use JDK 1.3 (The Swing stuff is improved a lot and the dacs are derived from them).
- Use Lov-Controls instead of Comboboxes wherever possible.
- Trace the sql-statements generated by the business-components and analyze the results. Mybe your code executes some queries unnecessarily.
- Build a prototype of a form with high complexity (much business logic) and check if this speed is sufficent for all your clients - this should be a KO-Criteria! If this test fails, you have to search for another architecture (JSPs).
But the most boostable advice is this: Try to reduce the data-transfer between your forms and the database as much as you can.
* Using a grid control is very convenient, but is it really necessary to fill it with a statment like SELECT * FROM BLAH_TABLE...?
* SetRestrictedQuery(...) with a parameter to reduce the transfer fo the query results of the LOV control.
* ViewLinks are fine - they fetch the detailed information only when its necessary.
* I doubt, that it will be a good three tier server side component design, but what about defining a View for complex joins in the database and wrap a bc-entity around it (of course you have to rethink your UI) instead of setting up different entities, views and view-links in the bc-layer?
What I really want to know is, if putting the bc-tier in the database will end up in better response time for applets. I won't go on this last adventure trip, if I'm not convinced that it will be worth the effort.
Can anyone admit or am I wrong in some points?
Have fun!
@i