1 / 17

Performance Tuning for ADF Applications: Reducing Memory Consumption

This presentation by Frank Houweling at Oracle Open World 2013 focuses on tuning ADF 11g applications to enhance performance and reduce memory consumption for the Dutch Ministry of Justice. With over 1000 concurrent sessions and response times exceeding 10 seconds, significant performance issues were identified. Key strategies included optimizing ViewObject access modes, implementing range paging to manage data effectively, and efficient application module pooling. By addressing these factors, the application’s responsiveness and resource utilization improved markedly.

gaerwn
Télécharger la présentation

Performance Tuning for ADF Applications: Reducing Memory Consumption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ADF Performance tuning war stories – reduce memory consumption Frank Houweling (AMIS, The Netherlands, Oracle Open World 2013)

  2. About me • Oracle ADF and Java specialist with AMIS (The Netherlands) • Focus on performance diagnosis and performance management • Many times troubleshooter in ADF projects with bad performance

  3. Customer case:Dutch ministry of Justice • Very poorly performing ADF 11g application • 1000+ concurrent sessions, 100+ concurrent requests • Response times over 10 seconds • Complaining end-users, testers, operations-teams

  4. Used Tool: ADF Performance Monitor • Monitors Slow HTTP requests • Shows the layer (Database, Model, e.g.) that causes the performance problem • Monitors JVM Heap and Garbage collection • Tracks all errors in your application

  5. Problem 1 • Huge JVM memory usage, long running garbage collections (>40 sec) • Root cause: • application data retrieved from the database into memory was not properly limited • Many rows (>25.000) with too many attributes in memory • Also rows and their attributes were retained in session for an unnecessary period of time

  6. What causes it • ViewObject’saccesmode is default Scrollable (VO tuning section) • Scrolling down an af:table retrieves and loads all rows from the database (!) Scrolling down

  7. Call stack shows how many rows are fetched

  8. Pattern: Table-Form layout Same ViewObject Screen Name Number Number Name Job Street ZipCode ………. Attribute N

  9. Rows and their attributes retrieved ViewObject No Name Job Street ZipCode Attribute N …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. ….

  10. Rows and their attributes needed ViewObject No Name Job Street ZipCode Attribute N …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. …. ….

  11. Solution • Reduce No. Columns retrieved • Dedicated ViewObjects for tableand form • Reduce No. Rows Retrieved • Set appropriate maximumfetchsize • Range Paging

  12. ViewObject Range Paging • Keeps only the current range (or "page") of rows in memory select * from ( <VIEWOBJECT QUERY> ) where rownum between <RANGE_START> and <RANGE_END> • If you have to ‘display’ > 500 records in a table

  13. ViewObject Range Paging

  14. Problem 2 • Starting the application was slow • Large ApplicationModules (AMs) • ApplicationModule ViewObjects, nested AMs are immediately instantiated • Very long running ApplicationModule pooling (>20 sec) • Application Pool too small • Too many attributes activated/passivated

  15. Application module size • Situation • 1 root ApplicationModule, 8 nested application modules, • > 1000 ViewObjects in total • View objects and nested AMs loaded on instantiation of application module • Solution • Sizing the Application module pool efficiently • Load the ViewObjects when they are needed (property Lazy Loading on AM or set JVM wide: -Djbo.load.components.lazily=true)

  16. ApplicationModule pooling guideline Oracle’s rule of thumb (Fusion Guide) • set the maxavailablesize and the recyclethreshold parameters to the expected number of peak concurrent users that perform operations with short think times: • jbo.ampool.maxavailablesize = jbo.recyclethreshold • jbo.ampool.minavailablesize = 80 % of jbo.ampool.maxavailablesize • jbo.ampool.doampooling=true (default) • jbo.doconnectionpooling=false (default) Result: • Avoids application module instantiation time when load increases - the hit is taken at server startup • Avoids recycling (passivation cycle) of AM under normal load

  17. Most common solutions • Avoid typical performance issues by • Implementing the Table-Form pattern using 2 separate view objects • Setting the appropriate tuning-values on the ViewObject • Sizing the Application module pool • Use lazy loading on ApplicationModules

More Related