oracle adf architecture tv - development - performance & tuning


Real World ADF Design & Architecture Principles

Performance & Tuning

15th Feb 2013 v1.0


Learning Objectives

•  At the end of this module you should be able to:

– How to prepare for performance by design – Setting realistic performance expectations – What to consider beyond ADF for performance – What to tune within the ADF stack

Image: imagerymajestic/ FreeDigitalPhotos.net


•  The requirements document specifies the application must be "performant"

•  A generic requirement states all pages for all 3 applications must return a response within ½ second

•  There is a specific requirement on the OStore product search page that it must be extremely fast

Non Functional Requirements

5 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 5 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Performance is a runtime goal that at design time is met by applying programming best practices. What does this

have to do with architecture?

Exercise


Shall we drop this session and have coffee instead?


Program Agenda

•  The quest for performance •  Performance

–  General Considerations –  ADF Business Components –  Controller –  UI Layer

7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Image: Ambro/ FreeDigitalPhotos.net

Performance tuning shouldn't be an after

thought


Security Dependencies Pick Any Two

Optimize Memory

Optimize CPU

Optimize Network


Start As You Mean to Go On

•  Performance goals are part of the requirements •  Establish those goals

–  Concentrate on the user experience –  Think “average” rather than min/max

•  Not all functions in the application need the same goals –  How often and by how many people? –  What is the user tolerance

•  Inevitably there will also be “reactive” tuning –  Plan for this in the schedule


Example Goal “The application must accommodate for long periods of time 300 simultaneously active users with response time average not to exceed 2 seconds. The application must accommodate a peak load of 600 active users for short durations of time with response time average not to exceed 7 seconds”

From: Techniques for Testing Performance/Scalability and Stress Testing ADF Applications March 2011

11 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 11 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

We're going to struggle to meet those benchmarks. Why?

Exercise



Preparing Your Baseline

•  Performance needs to be measured objectively and realistically

•  A bad testing regime can skew results vastly – Not unusual for results to be out by a factor of 10x ++ – So get your testing right!


Preparing Your Baseline

•  Define a representative workload on critical areas •  Test continuously or at least at the end of each sprint

–  It’s simpler to identify the cause of a performance problem at the time it is introduced

–  Test for both atomic performance and performance under stress –  How confident are you that the performance after a restart and

performance after 5 days running will be the same?


Testing Should…

•  Recognize that real users are not computers –  Define think time (can be used to scale tests) –  Use a sensible iteration time

•  Define a representative workload –  Length / nature of task –  Data distribution / records contention –  Numbers of users (aim high not low)

•  Be based on production parameters –  e.g. Session timeout


Testing Tools

•  UI unit testing ≠ functional testing ≠ performance testing –  (Although all are important)

•  Various tools are available for testing but you need more than screen automation

•  General recommendation suite based products –  e.g. Oracle Application Testing Suite (OATS)

•  Basically you need specialized staff or something you can write once and automate for normal developers


But What Can Developers Do?

•  Core testing should be automated or in the hands of professionals •  But, developers have some responsibilities to prevent or flag issues

–  How often is this fired? –  How much state am I holding? –  How many refreshes?

•  This leads us to…

Keeping an amateur eye on performance


“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” Structured Programming with go to Statements Computing Surveys, Vol 6, No 4, 1974; Donald Knuth


In a Nutshell

•  Never assume, never guess, measure –  Is an n-tier architecture even the correct choice?

•  Make the general assumption that ADF will probably get it right (or have a way of doing to) –  Consider the greater cost of do-it-yourself (DIY)

•  Look at the whole application end to end –  Observation - Most performance issues will be down to SQL

• Elapsed time or over execution –  Handle corner cases for what they are

Yes there is a design aspect to performance


Program Agenda




External Factors to Consider

•  Correct O/S setup –  HugePages, file descriptors etc.

•  JVM –  Server mode, generational parallel GC, optimized heaps

•  Application server –  Logging switched off, correct pool sizes

•  HTTP server –  Processes and threads

•  LDAP

This should only improve matters


Interacting With Web Services

•  First of all… Do you need to? •  Understand the issues

–  Calls are expensive –  Operations are (generally) atomic –  None of the usual semantics are standardized – transaction, array

fetching, DML

Performance Choice


Designing Dynamic Systems

•  Not wanting to specify an upper limit –  e.g. tabsets & regions

•  Insisting on a totally dynamic design –  How often do you actually need to customize?

•  Sticking with existing home-grown customization infrastructure •  Confusion between customization, personalization and security

configuration

Common issues effecting performance


Program Agenda




Application Modules

•  Take advantage of AM Sharing for “static” shared data –  ADF Mbeans provide hit rate info – accessible via EM

•  Use optimistic locking (Now the default in 11.1.2+ ) –  Better suited to browser deployed apps –  Reduce locking & rollback traffic on the DB

•  Avoid dependency on a specific connection –  For example PL/SQL package state

•  Use Oracle SQL rather than SQL92 •  Enable lazy loading of definitions

Basic Principles


AM Nesting

•  Provides: –  A service façade / interface –  Functional use case –  Test point –  Transactional container / connection owner

•  Not all AMs are equal –  Some are functional boundaries, some are conveniences –  Some are isolated, some are not

What does the AM actually do?


Application Module Pooling

•  Stop and read the documentation!

•  Excellent coverage in Fusion Developers Guide – Chapter 44 in 11.1.2 version “Tuning Application Module

Pools and Connection Pools”


What Happens on Passivation / Activation?

•  Passivation –  Passivation XML created

• Record diffs, current record pointers, bind variables, (transient attributes) , (custom user data Map)

–  XML written to DB

•  Activation –  XML read from DB –  User Map re-populated –  Prepare session code invoked –  Queries re-issued and result set scrolled

Scalability at a cost


Application Module Pooling

•  Use pooling of course (jbo.doconnectionpooling) –  Configuration based on user population

• initpoolsize – take the hit at server startup • Maxavailablesize – to your projected average peak

•  Aim to avoid passivation / activation costs –  Set recyclethreshold to maxavailablesize –  Bump up maxinactiveage –  Set timetolive = -1 –  Could save to up to 30% on response time

Recomendations


What About Database Connections?

•  First of all configure your AMs to use DataSources –  Abstracts the connection out of the application

•  Think in terms of AM pools rather than database connection pools –  Assuming 1 Root AM == 1 Connection (ignoring special cases)

•  Sizing –  Good rule of thumb is that one AM will serve between 10 and 15 users

comfortably –  Size for peak load based on this.

What you need to do


View Objects

•  VOs define the queries - so this is a key area •  The preference is to not write the SQL manually

–  You can loose out on optimizations –  Costly SQL is the no 1. performance problem in most systems

•  Base read-only VOs on EOs to use the cache •  Let the framework optimize attribute selection (wide EOs) •  Don’t be afraid of multiple VOs and multiple instances

General Principles


View Object Tuning Options


View Objects

•  Many knobs to turn –  The defaults are probably not what you need –  Consider the use case for each VO & build additional VOs or VO

instances if necessary…

•  Primarily consider the batch-size based on the usage •  Transient attributes – passivate or recalculate? •  Access Mode is very dependent on the use case

–  Implications of Page-Ranging - memory v’s network

Tuning Options


View Objects

•  Fetch Size decides number of records read from DB in one round trip –  JDBC implementation pre-allocates memory that matches with fetch size

to hold result set –  Set fetch size to range size of iterator in the page definition file + 3 –  For UI bound view objects, keep fetch size less than 30(not too high) –  The fetch size set for view object instance should be the maximum of

range size configured for all iterators bounds to that instance –  To improve reusability, specify the fetch size at view object usage level or

view accessor level

Detailed Tuning Tips


View Objects

•  Maximum Fetch Size decides total number of records that a view object can retrieve from database –  It will silently stop retrieving rows when the amount of rows reaches the

max fetch size. –  It is useful for either setting to 1 if you know you will only work with a

single row at a time, or for setting to a number like 10 for a "Top Ten" query where you have included an ORDER BY in the query and want to retrieve only the top ten rows in that sort order



View Objects

•  Range Size decides number of records read in to middle tier for a single data access –  If there are multiple UI components bound to same iterator, then range

size should be set as the maximum of all rows to be read for all the bounded components.

–  For range paging access mode, framework uses range size in building paginated queries

–  Range size set for iterators in page dentition (non zero value) overrides range size specified for the underlying view object



Tuning Tips

•  Globally setting row limit for view objects in an application –  Row Fetch Limit can be set globally in adf-config.xml (e.g. 500) –  It prevents a poorly formulated query from fetching a huge number of

rows –  You can override this at view object level by setting maximum fetch size

or by overriding getRowLimit() in ViewOblectImpl to return the appropriate value

Tuning Tips for View Objects


Tuning Tips

•  Use declarative query mode whenever possible –  Declarative solution for building query for a view object –  This mode causes view object to dynamically adjust the SELECT clause

to include only those columns used in the binding definition –  Not suitable for SQLs with complex WHERE clause

Tuning Tips for View Objects


View Objects

•  Use view criteria to conditionally append WHERE clause to the query

•  Mark at least one view criteria item as Required or Selectively Required

•  Index the columns in database table corresponding to the view criteria items marked as Required or Selectively Required

•  Avoid Contains and Ends With operators since DB index cannot be used on these queries.

Tuning Tips for View Criteria in a View Object


BC Tuning Gochyas

•  Fault-ins –  Explicit extra queries needed to populate attributes not directly populated

by the VO

The things we forget

EmpEO

Validation involving Sal

Fault-in Sal

Comm Sal is required for the validation

EmpVO EmpNo

FirstName LastName

Query

2nd Query

(where EmpNo

= :1)

EmpNo FirstName LastName

Sal Comm


Fault-Ins

•  A fault-in is not expensive – it’s a key lookup –  Assuming you have indexes –  But it’s still one round trip per row (not array fetched)

•  However, it could be a problem when you have 10s/100s of extra attributes or wide columns

•  Consider including attributes in core VOs if this is likely to effect a lot of rows

When does it matter?


Entity Objects

•  Always set primary key(s), –  Do not use default RowId. It is not guaranteed to be unique in clustered

environment

•  Avoid list validator –  If the list returns more rows. It fetches all rows sequentially .

•  Prefer to use get<AttributeName>() or getAttribute(int index) over getAttribute(String attributeName) –  For example empEO.getEmpName() is more performant than

empEO.getAttribute(“EmpName”)

Further best practice


Program Agenda




Controller Specific

•  Be aware of the implications of (not) sharing data controls •  Regions: convenience / reuse vs. cost

–  Each taskflow has an overhead

•  Enable HA and Customizations only if needed in adf-config.xml


Program Agenda




Pre-Deployment Tasks

•  Switch off “development mode” web.xml parameters –  Well documented in Tables 8-1 / 8-2 in the Oracle Fusion Middleware

Performance and Tuning Guide e.g. set oracle.adf.view.rich.CHECK_FILE_MODIFICATION to false

–  In most cases these options are OFF by default so you’ll only need to override those you have used

The switches you need to flip


ADF Faces Options

•  View State cache – how much page state history do we remember (for the back button) –  In web.xml:

–  Default value is 16 (15 old versions retained)

Things you didn’t know you were remembering…

<contextparam> <paramname> org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS </paramname> <paramvalue>2</paramvalue> </contextparam>


Cache what you can

•  View Root caching –  Optimization for AJAX UI which tend to have fewer screens

–  When view is changed, last component tree is discarded

<contextparam> <paramname> org.apache.myfaces.trinidad.CACHE_VIEW_ROOT </paramname> <paramvalue>true</paramvalue> </contextparam>


ADF Faces Options

•  Compress the View State cache –  Trades memory for CPU

–  Example customer application: •  Live memory reduced by 13% at a cost of 4.5% increase in CPU

And Squeeze…

<contextparam> <paramname> org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE </paramname> <paramvalue>true</paramvalue> </contextparam>


ADF Faces Options

•  Use WebCache, ADF auto-configures it for you •  Configure JS and Images to use the resource servlet

–  Sets cache header & reduces server file handle usage –  e.g. In web.xml:

Enable Resource Caching

<servletmapping> <servletname>resources</servletname> <urlpattern>/images/*</urlpattern> </servletmapping> <servletmapping> <servletname>resources</servletname> <urlpattern>/js/*</urlpattern> </servletmapping>


ADF Faces Options

Optimize JSP Servlet (11gR1 / R2 + JSPX)

<initparam> <paramname>load_description_from_tlds</paramname> <paramvalue>false</paramvalue> </initparam> <initparam> <paramname>jsp_timeout</paramname> <paramvalue>600</paramvalue> </initparam> <initparam> <paramname>debug_mode</paramname> <paramvalue>false</paramvalue> </initparam>

•  Again in web.xml


UI Code Changes

•  Don’t hold on to component references in pageflow / session scope (UIManager pattern) –  Breaks high availability, hogs memory and reflects bad coding practices

•  Defer loading for popups and regions in popups where possible –  childCreation=“deferred” for popups –  Activation=“conditional” for regions – switch on popupFetch event

(defined in pageDef)

You Certainly Should Make…


Components

•  Use short component IDs –  up to 10% page load time right there..

•  Only use clientComponent flag when actually needed –  The framework will automatically manage components mentioned

in PPR •  Use rendered rather than visible to control visibility

–  Less to send to the client – More secure

A few things to consider…


PPR

•  PPR needs to be designed –  Do use PPR whenever you can –  But, don’t refresh more than you need to

•  Take advantage of the PPR navigation feature –  When switched on, page transitions become a partial request –  e.g. on Fusion use cases, saves ~1second on page transition time.


“If you optimize everything you will always be unhappy.” Donald Knuth


Conclusion

•  Building for performance can occur at the design phase •  You need to set realistic expectations •  Tuning absolutely everything will get you no where


Further Reading

•  Oracle Fusion Middleware Performance and Tuning Guide 11.1.1.6.0 –  Section 8 – Oracle ADF Performance Tuning

•  http://bit.ly/VXH6bz

–  Techniques for Testing Performance/Scalability and Stress Testing ADF Applications •  http://bit.ly/13xOQTS


•  The requirements document specifies the application must be "performant"

•  A generic requirement states all pages for all 3 applications must return a response within ½ second

•  There is a specific requirement on the OStore product search page that it must be extremely fast

Non Functional Requirements

oracle adf architecture tv - development - performance & tuning

Technology

generic requirement states

requirements document specifies

response time average

fetch size

range size

tuning tips

specific requirement

view criteria