Beruflich Dokumente
Kultur Dokumente
Learning Objectives
Exercise
Performance is a runtime goal that at design time is met
by applying programming best practices. What does this
have to do with architecture?
Program Agenda
Performance tuning
shouldn't be an after
thought
Security Dependencies
Pick Any Two
Optimize
Memory
Optimize
Network
Optimize
CPU
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
10
Exercise
We're going to struggle to meet those
benchmarks. Why?
11
12
13
Testing Should
Recognize that real users are not computers
Define think time (can be used to scale tests)
Use a sensible iteration time
14
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)
15
This leads us to
16
17
In a Nutshell
Yes there is a design aspect to performance
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)
18
Program Agenda
19
JVM
Server mode, generational parallel GC, optimized heaps
Application server
Logging switched off, correct pool sizes
HTTP server
Processes and threads
LDAP
20
21
22
Program Agenda
23
Application Modules
Basic Principles
Take advantage of AM Sharing for static shared data
ADF Mbeans provide hit rate info accessible via EM
AM Nesting
What does the AM actually do?
Provides:
A service faade / interface
Functional use case
Test point
Transactional container / connection owner
25
26
Activation
XML read from DB
User Map re-populated
Prepare session code invoked
Queries re-issued and result set scrolled
27
28
Sizing
Good rule of thumb is that one AM will serve between 10 and 15 users
comfortably
Size for peak load based on this.
29
View Objects
General Principles
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
30
31
View Objects
Tuning Options
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
32
View Objects
Detailed Tuning Tips
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
33
View Objects
Detailed Tuning Tips
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
34
View Objects
Detailed Tuning Tips
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
35
Tuning Tips
Tuning Tips for View Objects
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
36
Tuning Tips
Tuning Tips for View Objects
37
View Objects
Tuning Tips for View Criteria in a View Object
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.
38
BC Tuning Gochyas
The things we forget
Fault-ins
Explicit extra queries needed to populate attributes not directly populated
by the VO
EmpVO
EmpEO
EmpNo
Query
FirstName
EmpNo
FirstName
LastName
LastName
Fault-in
Sal
Comm
uery
2 Q mpNo
re E
(whe :1)
=
nd
Sal
Validation
involving
Sal
Comm
39
Fault-Ins
When does it matter?
A fault-in is not expensive its a key lookup
Assuming you have indexes
But its still one round trip per row (not array fetched)
40
Entity Objects
Further best practice
Always set primary key(s),
Do not use default RowId. It is not guaranteed to be unique in clustered
environment
41
Program Agenda
42
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
43
Program Agenda
44
Pre-Deployment Tasks
The switches you need to flip
45
46
47
48
49
50
UI Code Changes
You Certainly Should Make
Dont hold on to component references in pageflow / session scope
(UIManager pattern)
Breaks high availability, hogs memory and reflects bad coding practices
51
Components
A few things to consider
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
52
PPR
53
54
Conclusion
55
Further Reading
56
57
58