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

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. 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

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
•  Performance
–  Controller
–  UI Layer

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
•  Performance
–  Controller
–  UI Layer

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
•  Performance
–  Controller
–  UI Layer

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
•  Performance
–  Controller
–  UI Layer

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie Oracle ADF Architecture TV - Development - Performance & Tuning

Ähnlich wie Oracle ADF Architecture TV - Development - Performance & Tuning (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Oracle ADF Architecture TV - Development - Performance & Tuning