This document discusses methods for improving performance in enterprise Java applications. It outlines an "ISYITF" method which stands for "do not do it...more often than required, on your own, immediately, as per request, in too big or too small steps, in a convoluted way, in a suboptimal place." The document provides examples of how to apply this method, such as reusing data, leveraging parallelism, batching requests, and pushing data rather than polling. It emphasizes optimizing resource usage by not overloading bottlenecks.
Thinking Through Java Enterprise Performance - Lucas Jellema - Oracle OpenWorld 2012
1. Lucas Jellema (AMIS, The Netherlands)
THINKING THROUGH
JAVA ENTERPRISE PERFORMANCE
JavaOne 2012, San Francisco
2. OVERVIEW
âą What is performance?
âą Where is performance established?
âą Advanced tuning methods
âą ISYITF Method for Performance Improvement:
â Do not do it âŠ
âą Architecting Enterprise Java applications for improved
performance
5. PERFORMANCE
Who determines in what way the performance
Expectations
Measure objectively
Business Owner
Process Duration Business Objectives
Wait time
SLAs
Availability â Performance
Disappearance Hourglass
Response time
Meaningful response
9. ADVANCED TUNING METHODS
âą Use StringBuffer rather than plain String concatenation
âą Use SAX for XML parsing instead of DOM
âą Carefully select the collection class to use
â optimize hashcode() in custom Map implementations
âą Use profiling tools to identify hotspots in the Java code
âą Remove Assertions from production code
âą Find optimal JVM switches through trial-and-error
â Focus on GC, Heap size, thread pools
âą Pool resources and reuse objects rather than recreate
âą Leverage concurrency features in Java to
â speed up time-to-completion through parallel execution
â prevent underuse of CPU during I/O operations
âą Optimize algorithms for sorting, pattern matching, iteration,
serialization, âŠ
20. DO NOT DO ITâŠ
MORE OFTEN THAN REQUIRED
âą If it has been produced beforeâŠ
â Reuse before re-produce!
âą If it has been shipped beforeâŠ
â Reuse instead of re-ship Web Browser
⹠⊠provided it is still fresh
JEE Application Server
RDBMS
21. DO NOT DO ITâŠ
MORE OFTEN THAN REQUIRED
âą Save on network trips, context
switches and tiers to cross
âą Save on âreproducingâ same results
-JS data (memory)
-Cookies Web Browser
- HTML 5 db
Edge Cache
Cache JEE Application Server
Cluster Fail-Over
(Session State)
Result Store
Write Behind
Client Result
Cache
Result Cache
RDBMS
Materialized
View
26. DO NOT DO ITâŠ
ON YOUR OWN
âą Parallel means: multiple resources contributing to a
task at the same time
âą Leverage multi-core CPU
âą Achieve scalability and performance with a Cluster
âą Introduce parallellism into your application
â Java: Concurrency (ThreadPools), WorkManager
â Database: parallel query and DML ,
dbms_parallel_execute, dbms_job, parallel table
functions
â Multi threading: on every tier and even across tiers
âą Engage compute grid: multi node processing unit
â For example: make Hadoop make those nodes work
for you (divvy up the work and merge the results)
29. THE POORLY PERFORMING
BUSINESS PROCESS LOAN REQUEST
Reject
request
Check Identity
Loan Evaluate
request
with Federal Fraud Analysis
Request
Service
Transfer
Money
Max 1 day Max 2 days Max 3 days Max 3 mins
98% is OK 99.99% is OK
Max 6 days + 3 mins
30. THAT DINNER IS TAKING MIGHTY
LONGâŠ
Dinner is
Served
All are
satisfied
Max 3 hours + 3 mins
31. THE DINNER PROCESS
Dinner is John eats Mary eats Daisy Marty
Served soup soup eats soup eats soup
Daisy Marty
John eats Mary eats
eats eats
main main
main main
Daisy
John eats All are
eats satisfied
desert
desert
Max 3 hours + 3 mins
32. THE SAME DINNER PROCESS
John eats John eats
soup main
John eats
Mary eats Mary eats desert
Dinner is
soup main All are
Served satisfied
Daisy Daisy
Daisy eats
eats eats
soup
main desert
Marty
Marty
eats
eats soup
main
Max 3 hours + 3 mins
33. THE OPTIMIZED DINNER PROCESS
John eats John eats
soup main
John eats
Mary eats Mary eats desert
soup main
Dinner is All are
Served satisfied
Daisy Daisy
Daisy eats
eats eats
soup
main desert
Marty
Marty
eats
eats soup
main
Max 1 hours + 3 mins
34. FURTHER OPTIMIZATIONS
(IF NOT REFINEMENT)
John eats John eats
soup main
John eats
Mary eats Mary eats desert
soup main
Dinner is All are
Served satisfied
Daisy Daisy
Daisy eats
eats eats
soup
main desert
Marty
Marty
eats
eats soup
main
Max 53 mins
35. THE POORLY PERFORMING
BUSINESS PROCESS LOAN REQUEST
Reject
request
Check Identity
Loan Evaluate
request
with Federal Fraud Analysis
Request
Service
Transfer
Money
Max 1 day Max 2 days Max 3 days Max 3 mins
98% is OK 99.99% is OK
Max 6 days + 3 mins
36. SPEEDING UP THE BUSINESS
PROCESS LOAN REQUEST
Check Identity
with Federal
Service Reject
request
Loan
request
Fraud Analysis
Transfer
Evaluate Money
Request
Max 1 day Max 3 mins
Max 2 days
Max 3 days
Max 3 days + 3 mins
45. DO NOT DO ITâŠ
IMMEDIATELY (OR SYNCHRONOUSLY)
âą Submit information, file a complaint or request, start a
process, trigger interaction
â No immediate response is required!
âą Asynchronous
â Start batch job (db) or worker-thread (java)
âą Or fire event
â Write behind (from grid) (NO SQL)
â DML Error log
46. DO NOT DO ITâŠ
IN BATCH (UN-IMMEDIATELY)
âą Batch jobs can put peak load on a system â choking
on line applications
â Monthly reporting, quarterly prolongation, yearly
calculation,
âą Batch jobs are increasingly unwanted in 24/7
â When is the ânightlyâ batch window?
â Data not current (enough) by todayâs standards: âbatch
has not run yetâ
âą Batch jobs used to be desirable or needed as a result
of technical limitations â that may not apply anymore
âą Continuous, near real-time operations â leveraging
events, decoupling and integration architectures â are
a serious alternative
48. ISYITF METHOD
FOR PERFORMANCE IMPROVEMENT
DO NOT DO IT âŠ
AT ALL
MORE OFTEN THAN REQUIRED
ON YOUR OWN
IMMEDIATELY
AS PER REQUEST
49. DO NOT DO ITâŠ
AS PER REQUEST
âą Push has two key advantages over poll
â Most up to date information
â Reduction in network traffic and load on server
âą Push is available in several flavors
â Middleware to Browser: comet, ADF Active Data
Service, WebLogic Server HTTP Channels, long poll,
WebSockets in HTML 5
â Database to Middleware: JMS/AQ, Database Query
Result Change Notification, Table Triggers, utl_http
push to servlet
â âpiggy backingâ â adding subscribed-to information in
regular requests
âą Event driven architecture is
based on push (of events) to
mediating event handling
infrastructure
51. ISYITF METHOD
FOR PERFORMANCE IMPROVEMENT
DO NOT DO IT âŠ
AT ALL
MORE OFTEN THAN REQUIRED
ON YOUR OWN
IMMEDIATELY
AS PER REQUEST
IN TOO BIG OR TOO SMALL STEPS
52. DO NOT DO ITâŠ
IN TOO BIG STEPS
âą Performance perception is often: time until page is
displayed and accessible (hourglass disappears)
âą Web pages frequently contain much more than is
initially visible or even required
â Tree nodes, inactive tabs, invisible popups, unopened
dropdown lists
âą Performance perception can be enhanced by not
initially loading what is not required
âą Use AJAX based post-loading to (lazy-)fetch content in
subsequent, background round-trips
âą /*+ First Rows */ vs. /*+ All Rows */
53. PENSION FUND â SEPTEMBER 2012
Employer < >
Participants
Job & Benefits
54. FETCHING THE DATA OF THE PENSION
FUND FOR THE WEB APPLICATION
select *
1 record
< >
from employers
where id = < 324>
select * 100s records
from participants
where employer_id = < 324>
select * 10s records
from benefits
where participant_id = <#>
55. REPORTING ON MANY EMPLOYERS
select *
100s records
from employers 1 query
select * 10k records
from participants 100s queries
where employer_id = <#>
select * 100k records
from benefits 10k queries
where participant_id = <#>
56. SINGLE BULK RETRIEVE REPLACING
MULTIPLE QUERIES
âą Have the database bulk up the data retrieval
âą Return Ref Cursor, Types and Collections or
JSON/XML
Benefits Package
select *
from employers
where id in <some set> select *
from participants
where employer_id in <some set>
select b.*
from benefits b join participants p
on (p.id = b.participant_id)
where p.employer_id in <some set>
57. DO NOT DO ITâŠ
IN TOO BIG OR TOO SMALL STEPS
âą Every network round-trip and context-switch adds
overhead
â Compare dialing the operator for every digit in the
telephone number you want to learn about
âą Bundling up information to reduce the number of
round trips can be advantageous for performance
â Bring all items from the shop in one round trip
â Leverage collections and types, XML or JSON to
retrieve complex, structured object graphs from DB
â Zipping up multiple web resources in single archive
â Mashing up icons or images into a single big picture
â Piggy-back information onto requests
60. ISYITF METHOD
FOR PERFORMANCE IMPROVEMENT
DO NOT DO IT âŠ
AT ALL
MORE OFTEN THAN REQUIRED
ON YOUR OWN
IMMEDIATELY
AS PER REQUEST
IN TOO BIG OR TOO SMALL STEPS
IN A CONVOLUTED WAY
61. DO NOT DO ITâŠ
IN A CONVOLUTED WAY
âą Pragmatism can overcome theoretical purity (or old
dogsâ tricks)
â With good reason and well documented
âą Have client side Java Script directly access Google
Maps â by-passing the application server
âą Have client directly access Database services
âą Use RESTful (JSON, CSV) rather than WS* and XML
between browser client and application server
âą Use POJOs (Entities) throughout the application, from
JPA to Web Tier â rather than copying/transferring
âą When that suffices, use simple substring i/o parsing
big xml in DOM
âą Pass plain CSV/JSON/XML from DB through Java
middle tier to Client when that is appropriate
63. ISYITF METHOD
FOR PERFORMANCE IMPROVEMENT
DO NOT DO IT âŠ
AT ALL
MORE OFTEN THAN REQUIRED
ON YOUR OWN
IMMEDIATELY
AS PER REQUEST
IN TOO BIG OR TOO SMALL STEPS
IN A CONVOLUTED WAY
IN A SUBOPTIMAL PLACE
64. BOTTLENECK / CRITICAL CHAIN
âą Make sure that the bottleneck resource in your
enterprise application is not used (at peak times) for
work that is not critical or that can be outsourced
â Use auxiliary resources â outside critical chain
â Engage specialized servers, optimized for specific
tasks
â Manage resources in a strict manner
âą Resource manager (DB) or Work manager (WLS)
65. DO NOT DO IT⊠LIVE EVENT PROCESSING
IN A SUBOPTIMAL PLACE
âą The league of real time events
â Continuous stream of a multitude of tiny events with
hardly any payload, to analyze & aggregate
â Sent from physical sensors
(temperature, pressure, RFID, security gates), process
sensors, Twitter, manufacturing equipment, database
triggers, web servers, ESBs, stock trade tickers, sport
statistics, RSS, network switches, âŠ
66. DO NOT DO IT⊠HTML RENDERING
IN A SUBOPTIMAL PLACE
âą (X)HTML is not very compact
â Information density of HTML is very low
âą DHTML, JavaScript &
AJAX allow for Web Browser
â Dynamic HTML
rendering in browser
â Dynamic, Partial
Page Refresh
âą Most HTML presented JEE Application Server
by application is pre-
defined
â Dynamic data content
fetched from RDBMS
or other services is
small fraction RDBMS
67. DO NOT DO ITâŠ
IN A SUBOPTIMAL PLACE
âą Do not perform a task in a resource that is not ideally
suited for that task
â If it directly contributes to overall performance
68. DO NOT DO ITâŠ
IN A SUBOPTIMAL PLACE
âą Leverage database for what itâs good at
â Data Integrity â Primary Key /Unique Key /Foreign Key
â Aggregation
â Sorting
â Data Rule enforcement
â Bulk DML and Copy data
â Analytical Functions, Model clause, Rollup
âą Specialized engines for
â Imaging and Document Processing
â Match and Search
â Speech Recognition
â Cryptography
â 3D
â Real time Data Processing
â âŠ.
69. ISYITF METHOD
FOR PERFORMANCE IMPROVEMENT
DO NOT DO IT âŠ
AT ALL
MORE OFTEN THAN REQUIRED
ON YOUR OWN
IMMEDIATELY
AS PER REQUEST
IN TOO BIG OR TOO SMALL STEPS
IN A CONVOLUTED WAY
IN A SUBOPTIMAL PLACE
71. ARCHITECT(URE) FOR PERFORMANCE
Services ( Google Maps,
Translation, Conversion,
Data Feeds
-JS data (memory) Web Browser
-Cookies HTML rendering
- HTML 5 local db Validation, Calculation, Parsing
âProcessingâ (image, cryption, compression, SETI)
Fire&Forget
piggy- Post load
back (AJAX)
by-pass
JEE Application Server
72. ARCHITECT(URE) FOR PERFORMANCE
Services ( Google Maps,
Translation, Conversion,
Data Feeds
-JS data (memory) Web Browser
-Cookies HTML rendering
- HTML 5 local db Validation, Calculation, Parsing
âProcessingâ (image, cryption, compression, SETI)
Fire&Forget
push piggy- Post load
back (AJAX) by-pass
Search
Edge Cache Load balancer &
Match
Sticky ip sessions, Throttling CEP
Cache
CMS
Cluster Fail-Over JEE JEE Compute
WorkManager
(Session State) App App Parallel Threads Grid
Result Store Server Server JMS Crypto
Write Behind
Node Node Node Image
Print
Server
73. ARCHITECT(URE) FOR PERFORMANCE
by-pass
Search
Edge Cache Load balancer &
Match
Sticky ip sessions, Throttling CEP
Cache
CMS
Cluster Fail-Over JEE JEE Compute
WorkManager
(Session State) App App Parallel Threads Grid
Result Store Server Server JMS Crypto
Write Behind
Node Node Node Image
push Print
Server
Fire&Forget
Client Result Post
Cache load
AQ/JMS
HTTP Push
DB QRCN
Result Cache
Aggregation
Resource Mgt
Materialized Filter & Sort
Jobs
Data Integrity
View Bulk DML Pipelining
Parallel Processing
CBO RDBMS
74. Services ( Google Maps,
Translation, Conversion,
Data Feeds
-JS data
(memory)
Web Browser
HTML rendering
-Cookies Validation, Calculation, Parsing
- HTML 5 local db âProcessingâ (image, cryption, compression, SETI)
Post load
Fire&Forget
push piggy-
back (AJAX)
by-pass
Edge
Cache Load balancer
Sticky ip sessions, Throttling
CEP
Cache JEE JEE CMS
Cluster Fail-Over Compute
(Session State) App App WorkManager
Grid
Parallel Threads
Result Store Serv Serv JMS Cryp
Write Behind erNo erNo to
Node
de de Image
push Print
Server
Fire&Forget
Client Result Post
Cache load
AQ/JMS
HTTP Push
DB QRCN
Result
Cache Aggregation Resource Mgt
Materialized Filter & Sort Jobs
View Data Integrity Pipelining
Bulk DML Parallel Processing
CBO
RDBMS
75. SUMMARY
âą Performance requirements are derived from
measurable and meaningful business objectives
âą Unavailability equals Zero Performance
â Treat Performance and Availability elements in the
same equation
âą Performance should [also] be addressed in a top-down
approach, across all tiers and constituent parts
âą Some ISYITF guidelines:
â Do not do it ⊠[AT ALL | MORE OFTEN THAN
REQUIRED | ON YOUR OWN | IMMEDIATELY | AS
PER REQUEST | IN TOO BIG OR TOO SMALL
STEPS | IN A CONVOLUTED WAY | IN A
SUBOPTIMAL PLACE ]
Notas do Editor
Process
Na een upgrade van SOA Suite 10g (ESB) naar OSB 11g, 65% slechtereresponsetijd
Na een upgrade van SOA Suite 10g (ESB) naar OSB 11g, 65% slechtereresponsetijd
ISYITF = it is staring you in the face
Cache â spreekuit: kasjeKastjesBrowser: Client (browser, cookie or Java Script memory; HTML 5 offers persistent, cross session local db like storage)App Server : Edge (WebServer)JVM (and cluster)Cross cluster shared cachedb or memory gridDatabase (not requery at least)
http://thecleancoder.blogspot.com/2010/08/why-clojure.htmlWhat this means is that our computers can still get faster, but only if we put multiple CPUs on a chip. This is why we've seen all these multi-core processors showing up. And thatmeans that programs that need greater speed will have to be able to take advantage of the multiple cores.
Additional bar tendersNo improved performanceIn fact: some degradation(new) Bottleneck: coffee machinesSystem is I/O bound, increase CPU will only increase the âthreading overheadâ and degrade performanceSame with more toilets: the washing basins become the new bottle neckSynchronization points
Compare ECT:Unload all containers, than start moving out (train?)Unload one, put on truck and start driving; then unload next one
Plaatje van printerPrint Job wordtnaar printer gestuurdWil je zandloper tot de printer klaar is met de klus?Of een melding âjob has startedâ en doorgaan met je werk
Do not do (synchronous) work in resources that are not ideally equipped/do that work in a suboptimal way
Copy data in PL/SQL (rather than bring from DB to Middletier, copy, send back again)