Looking at performance may quickly become a tuning exercise, the hunt for the last 2% algorithmic improvement or JVM parameter readjustment. This presentation takes a somewhat more removed look at Enterprise Java performance - taking in the broader picture of the entire multi-tier architecture and applying common sense performance concepts from every day life an applying those to enterprise Java architectures. To serve as an eye opener. (originally created for the Oracle Technology Day on Java Enterprise Performance, May 2011, The Netherlands)

1. Verlichte Java Applicaties Oracle Technology Daya – Enterprise Java Performance

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

3. Performance Degradation 65 %

4. Performance Degradation Response time + 65 %

5. Performance Who determines in what way the performance Expectations Measure objectively Business Owner Business Objectives Process Duration Wait time SLAs What is start and what is end of action Availability ≈ Performance Disappearance Hourglass Response time Meaningful response

6. The Theater manager

7. Typical Layout of Enterprise Java applicatiONS Performance ≈ Wait for Response Web Browser JEE Application Server RDBMS

8. Performance contributors in Enterprise Java applicatiONS Performance ≈ Wait for Response Web Browser Response = Wait + Processing Wait = Network 1 + Response AppServer 1 JEE Application Server Response = Wait + Processing Wait = Network 2 + Response Database 2 RDBMS Response = Processing Processing = internal wait (I/O) + CPU

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, …

10. ISYITF Method for Performance improvement The fastest way to perform a task: DO NOT do it

11. Prevent unneeded processing if ( expensiveEvaluation & someFlag) { ...} if (someFlag && expensiveEvaluation) { ...}

12. Prevent unneeded processing log.debug ( “Outcome step 2: ” + resultOfExpensiveProcessing ); if (log.doDebug) log.debug ( “Outcome step 2: ” + resultOfExpensiveProcessing );

13. The shopping algorithm

14. The Shopping algorithm shopForItem Item ( String itemName) {driveToShop; Item item = buyItemAtShop ( itemName);driveHomeFromShop; return item;}

15. Get this week’s groceries getGroceries Item[] ( String[] shoppingList) { Item[] items = new Item[ shoppingList.length]; for (inti=0; i < shoppingList.length; i++) { items[i] = shopForItem (shoppingList[i]); } return items;}

16. ISYITF Method for Performance improvement At All At All More often than required DO NOT do it

17. Sweet memories

18. Stock management

19. Stock management

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 … provided it is still fresh Web Browser JEE Application Server RDBMS

22. Cookies

23. HTML 5 dbEdge Cache JEE Application Server Cache Cluster Fail-Over (Session State) Result Store Write Behind Client Result Cache RDBMS Result Cache Materialized View

24. More performance requires parallel

25. More performance requires parallel

26. ISYITF Method for Performance improvement DO NOT do it … At All More often than required On your own

27. Moore’s law revised: cores law

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

29. Balance resources to Prevent Clogging

30. Pancake Party

31. Better performing Pancake Party

32. Pipelined Pancake Party: best performance

33. Pipelined Pancake Party Parallel Pipelined: multiple different resources working on different components of the task in [potentially] different tiers From batch processing to unit processing => pass the unit on for further processing as soon as part of the task is done – to leverage resources (across tiers) in parallel Instead of baking the entire stack first and only then eating it… … start eating as soon as the first one is done Even the last guest ends earlier than without pipelining provided he eats more than one pancake (he eats his first pancake when it is done, not when the stack is done) The first eater is done much sooner first rows/all rows ≈ first pan cake/all pan cakes

34. Pipelining across the tiers Database: Pipelined Table Functions Pipes and Queues Middle tier: Multiple threads Queues (JMS) Client tier: AJAX “channels” WebSockets Web Browser RDBMS

35. The pinnacle of un-performance

36. Fire and forget

37. ISYITF Method for Performance improvement DO NOT do it … At All More often than required On your own immediately

38. fire and forget in the real world

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

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

41. Don’t call us … we’ll call you

42. ISYITF Method for Performance improvement DO NOT do it … At All More often than required On your own immediately As per request

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

44. Bite off more than you can Have to chew

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

46. 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 */

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

48. The hard way

49. a convoluted way

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

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

52. Bottleneck / Critical chain

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

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

55. Do not do it… LIVE Event processingIn 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, …

56. Do not do it… HTML RenderingIn a suboptimal place (X)HTML is not very compact Information density of HTML is very low DHTML, JavaScript &AJAX allow for Dynamic HTMLrendering in browser Dynamic, PartialPage Refresh Most HTML presentedby application is pre-defined Dynamic data contentfetched from RDBMSor other services issmall fraction Web Browser JEE Application Server RDBMS

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

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

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

60. Architect For Performance Web Browser JEE Application Server RDBMS

62. Cookies

63. HTML 5 local dbWeb Browser HTML rendering Validation, Calculation, Parsing “Processing” (image, cryption, compression, SETI) Post load (AJAX) piggy-back Fire&Forget by-pass JEE Application Server

65. Cookies

66. HTML 5 local dbWeb Browser HTML rendering Validation, Calculation, Parsing “Processing” (image, cryption, compression, SETI) Post load (AJAX) piggy-back push Fire&Forget by-pass Edge Cache Search& Match Load balancer Sticky ip sessions, Throttling CEP Cache CMS JEE AppServerNode JEE AppServerNode Node Cluster Fail-Over (Session State) Result Store Write Behind Compute Grid WorkManager Parallel Threads JMS Crypto Image Print Server

67. Architect(ure) for performance by-pass Edge Cache Search& Match Load balancer Sticky ip sessions, Throttling CEP CEP Cache CMS CMS JEE AppServerNode JEE AppServerNode Node Cluster Fail-Over (Session State) Result Store Write Behind Compute Grid Compute Grid WorkManager Parallel Threads JMS Crypto Crypto Image Image Print Server Print Server push Client Result Cache Postload Fire&Forget AQ/JMS HTTP Push DB QRCN RDBMS REST API Result Cache Aggregation Filter & Sort Data Integrity Bulk DML Resource Mgt Jobs Pipelining Parallel Processing Materialized View CBO

69. Cookies

70. HTML 5 local dbWeb Browser HTML rendering Validation, Calculation, Parsing “Processing” (image, cryption, compression, SETI) Post load (AJAX) push piggy-back Fire&Forget by-pass Edge Cache Load balancer Sticky ip sessions, Throttling CEP Cache CMS JEE AppServerNode JEE AppServerNode Node Cluster Fail-Over (Session State) Result Store Write Behind Compute Grid WorkManager Parallel Threads JMS Crypto Image Print Server push Client Result Cache Postload Fire&Forget AQ/JMS HTTP Push DB QRCN RDBMS REST API Result Cache Aggregation Filter & Sort Data Integrity Bulk DML Resource Mgt Jobs Pipelining Parallel Processing Materialized View CBO

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