JMP401: Masterclass: XPages Scalability

56 %
44 %
Information about JMP401: Masterclass: XPages Scalability
Technology

Published on February 5, 2014

Author: tmcguckin

Source: slideshare.net

Description

IBM Connect 2014: JMP401: Masterclass: XPages Scalability

JMP401: Masterclass: XPages Scalability Tony McGuckin, IBM Martin Donnelly, IBM © 2014 IBM Corporation

Please Note IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.

“You've taken the XPages Performance Master Class. You've also taken the XPages Master Class Video Series 1. Now sit back and experience the next level... the "X" level! Learn how to take that finely tuned “performance master class" application to its absolute "scalability" limits. Bring "performance" and "scalability" together once and for all!”

Good Morning! Welcome to JMP401… Tony McGuckin Senior Software Engineer Ireland Software Labs @tonymcguckin Martin Donnelly Software Architect Ireland Software Labs @tweeterdonnelly

This Morning's Agenda… Understanding the “XPages Machine” Developing for Performance Architecting for Scalability Q&A

Caution: May Contain Nuts... This session is heavily based upon material taken from the new, upcoming Mastering XPages, Second Edition book from IBM Press. Where applicable the presenters will suggest further reading available from this book about topics in this session. It is available now for pre-order from Amazon.com and all good bookshops! 6

Understanding the “XPages Machine”

Understanding the “XPages Machine” The Performance and Scalability Pyramid Performance and Scalability are two separate entities Each can conflict with the interests and goals of the other

Understanding the “XPages Machine” The Performance and Scalability Pyramid Performance and Scalability are two separate entities Each can conflict with the interests and goals of the other

Understanding the “XPages Machine” The Performance and Scalability Pyramid Consider the following...

Understanding the “XPages Machine” The Performance and Scalability Pyramid “It performs really well, most requests only take a second or two when it's not busy, but it gets really slow when everyone's on the system... up on ten seconds or more for requests when about three hundred users are logged in... just seems to fall over at about one hundred users!” Some Sales Lead, Acme Global Business Corp. A case of not being able to scale up or out (vertical / horizontal scale)... performance probably maintainable if vertical scale was corrected (→ Product / Hardware Tuning)

Understanding the “XPages Machine” The Performance and Scalability Pyramid “It's always so slow... about eight seconds on average to complete workflow actions... this is regardless of how many of us are on it... first thing in the morning, last thing at night! One user, one thousand users... does'nt matter! It's never fails though I'll give it that much!” An Office Manager, Some Online Shop. A case of being able to scale up and/or out (vertical / horizontal scale) but performance needs corrective action (→ Design/Code Tuning)

Understanding the “XPages Machine” The Performance and Scalability Pyramid Finding a balance between Performance and Scalability is the end goal!

Understanding the “XPages Machine” The Performance and Scalability Pyramid Remember this though...

Understanding the “XPages Machine” The Performance and Scalability Pyramid Performance and Scalability are not discrete features you can just turn on at some point! Both need to be built-in and designed for from the start! Clearly defined expectations of upper limits on response times and user load should be agreed

Understanding the “XPages Machine” The Performance and Scalability Pyramid Performance and Scalability are not discrete features you can just turn on at some point! Both need to be built-in and designed for from the start! Clearly defined expectations of upper limits on response times and user load should be agreed

Understanding the “XPages Machine” The Performance and Scalability Pyramid Performance and Scalability are not discrete features you can just turn on at some point! Both need to be built-in and designed for from the start! Clearly defined expectations of upper limits on response times and user load should be agreed

Understanding the “XPages Machine” The Performance and Scalability Pyramid  Layers of Tuning include all relevant factors from architectural design, actual source code implementation, host product such as server middleware, and the actual hardware environment Layers of Tuning Hardware Product Code  Degree of Impact is largest at the bottom of the pyramid. Positive changes to design and code will always yield most Design Degree of Impact

Understanding the “XPages Machine” XPages and the JavaServer Faces® Framework  JavaServer Faces® Reference Implementation (aka JSF RI) ─ Provides an extensible Component based development model and framework ─ Provides a Stateful runtime for Server-Side User-Interfaces / Java Applications ─ Provides a Server-Side EL Scripting / Binding Model ─ Part of the J2EE specification / stack –  http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html XPages extends the JSF RI Implementation ─ Provides Specialized Controls and DataSources for N/D application development (plus Social/REST/RDBMS/…) ─ Provides Extended and Optimized Component / View Event Model – Tightly integrated with Client-Side and Server-side Scripting Models – Specialized Partial Refresh and Partial Execution Models ─ Provides Server-Side EL, Client-side JavaScript / SSJS, and XPath Scripting / Binding Model ─ Provides Specialized Stateful Runtime for highly optimized application behavior

Understanding the “XPages Machine” XPages and the JavaServer Faces® Framework  JavaServer Faces® Reference Implementation (aka JSF RI) ─ Provides an extensible Component based development model and framework ─ Provides a Stateful runtime for Server-Side User-Interfaces / Java Applications ─ Provides a Server-Side EL Scripting / Binding Model ─ Part of the J2EE specification / stack –  http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html XPages extends the JSF RI Implementation ─ Provides Specialized Controls and DataSources for N/D application development (plus Social/REST/RDBMS/…) ─ Provides Extended and Optimized Component / View Event Model – Tightly integrated with Client-Side and Server-side Scripting Models – Specialized Partial Refresh and Partial Execution Models ─ Provides Server-Side EL, Client-side JavaScript / SSJS, and XPath Scripting / Binding Model ─ Provides Specialized Stateful Runtime for highly optimized application behavior

Understanding the “XPages Machine” XPages Specific Extensions / Capabilities over JSF RI ─ XPage and Custom Control introduced – .xsp file format and Java Component API for creating/managing component tree ─ Request Processing Lifecycle optimizations and extensions ─ Dynamic Component Tree API introduced ─ loaded property introduced ─ rendered property optimized to avoid/reduce multi-execution in the render-response phase ─ disableValidators property introduced ─ Partial Execution introduced allowing control of execution area (execMode / execId) ─ renderWholeTree partial refresh optimization introduced ─ viewScope variable introduced ─ id: resolution introduced ─ View Level Events introduced (beforePageLoad, afterPageLoad, etc)

Understanding the “XPages Machine” XPages Specific Extensions / Capabilities over JSF RI ─ View Level Events introduced (beforePageLoad, afterPageLoad, etc) ─ eventHandler c/w new Simple Actions introduced ─ Extended EL objects introduced (session, sessionAsSigner, database, etc) ─ Javascript Binding introduced ─ XPath Binding introduced ─ ServerSide JavaScript scripting / SSJS & Java API introduced ─ Domino DataSources plus many others introduced ─ Highly configurable State Management / Persistence Layer introduced ─ Computed SSJS Expressions in faces-config.xml introduced ─ repeat control introduced (plus many other controls) ─ XPages Extension Library introduced, … the list goes on, and on, and on...

Understanding the “XPages Machine”  Important to understand the core principles of XPages to gain maximum Performance and Scalability, and ensure Data Integrity ─ Stateful Web Application Framework – – ─ Saving and Restoring State State Machine / Parallel Universe between client/browser and server Component-Based Architecture – Every Tag has a server-side Object representation – An XPage is a hierarchical Component Tree ─ Conversion and Validation must be handled consistently as Data Integrity is paramount ─ Six Phase XPages Request Processing Lifecycle (X-RPL) ─ Governs the processing of every XPages request – Server-side Memory and CPU usage should be minimized

Understanding the “XPages Machine”  Important to understand the core principles of XPages to gain maximum Performance and Scalability, and ensure Data Integrity ─ Stateful Web Application Framework – – ─ Saving and Restoring State State Machine / Parallel Universe between client/browser and server Component-Based Architecture – Every Tag has a server-side Object representation – An XPage is a hierarchical Component Tree ─ Conversion and Validation must be handled consistently as Data Integrity is paramount ─ Six Phase XPages Request Processing Lifecycle (X-RPL) ─ Governs the processing of every XPages request – Server-side Memory and CPU usage should be minimized

Understanding the “XPages Machine”  Important to understand the core principles of XPages to gain maximum Performance and Scalability, and ensure Data Integrity ─ Stateful Web Application Framework – – ─ Saving and Restoring State State Machine / Parallel Universe between client/browser and server Component-Based Architecture – Every Tag has a server-side Object representation – An XPage is a hierarchical Component Tree ─ Conversion and Validation must be handled consistently as Data Integrity is paramount ─ Six Phase XPages Request Processing Lifecycle (X-RPL) ─ Governs the processing of every XPages request – Server-side Memory and CPU usage should be minimized

Understanding the “XPages Machine”  Important to understand the core principles of XPages to gain maximum Performance and Scalability, and ensure Data Integrity ─ Stateful Web Application Framework – – ─ Saving and Restoring State State Machine / Parallel Universe between client/browser and server Component-Based Architecture – Every Tag has a server-side Object representation – An XPage is a hierarchical Component Tree ─ Conversion and Validation must be handled consistently as Data Integrity is paramount ─ Six Phase XPages Request Processing Lifecycle (X-RPL) ─ Governs the processing of every XPages request – Server-side Memory and CPU usage should be minimized

Understanding the “XPages Machine” Factors that effect Performance and Scalability A Browser/Device has work to do in order to process any given request or response:       Resource Caching Size of request or response Number of requests and responses Parsing of JavaScript / CSS Calculating the layout Painting / Rendering the final page A Network experiences its own stress and load issues:     Bandwidth Latency Contention Interference A Distributed System Architecture presents its own challenges:      Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation The Host System has two critical parts that determine how an application behaves:   CPU Memory (RAM & Disk)

Understanding the “XPages Machine” Factors that effect Performance and Scalability A Browser/Device has work to do in order to process any given request or response:       Resource Caching Size of request or response Number of requests and responses Parsing of JavaScript / CSS Calculating the layout Painting / Rendering the final page A Network experiences its own stress and load issues:     Bandwidth Latency Contention Interference A Distributed System Architecture presents its own challenges:      Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation The Host System has two critical parts that determine how an application behaves:   CPU Memory (RAM & Disk)

Understanding the “XPages Machine” Factors that effect Performance and Scalability A Browser/Device has work to do in order to process any given request or response:       Resource Caching Size of request or response Number of requests and responses Parsing of JavaScript / CSS Calculating the layout Painting / Rendering the final page A Network experiences its own stress and load issues:     Bandwidth Latency Contention Interference A Distributed System Architecture presents its own challenges:      Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation The Host System has two critical parts that determine how an application behaves:   CPU Memory (RAM & Disk)

Understanding the “XPages Machine” Factors that effect Performance and Scalability A Browser/Device has work to do in order to process any given request or response:       Resource Caching Size of request or response Number of requests and responses Parsing of JavaScript / CSS Calculating the layout Painting / Rendering the final page A Network experiences its own stress and load issues:     Bandwidth Latency Contention Interference A Distributed System Architecture presents its own challenges:      Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation The Host System has two critical parts that determine how an application behaves:   CPU Memory (RAM & Disk)

Understanding the on the Host System area: This morning we are focusing “XPages Machine” Factors that effect Performance and Scalability #1 Understanding the XPages Request Processing Lifecycle is critical to write highly efficient code with a low vertical cost → Primary objective is minimizing CPU usage A Browser/Device has work to do in order to → any given request or is minimizing Memory usage processSecondary objectiveresponse:  A Distributed System Architecture presents its own challenges: Resource Caching #2 Understanding the XPages State Management Layer is Data Replication & Indexing Size of request or response equally as important and write highly efficient code, but also forConflict Resolution Number of requests to responses On/Offline Execution (XPiNC) Parsing / tuning an application and the XPages Runtime to configuringof JavaScript / CSS Node Availability / Failover Calculating the layout achieve a low horizontal cost Design Propagation Painting / Rendering the final page → Primary objective is minimizing Memory usage           → Secondary objective is minimizing CPU usage A Network experiences its own stress and load issues:     Bandwidth Latency Contention Interference The Host System has two critical parts that determine how an application behaves:   CPU Memory (RAM & Disk)

Understanding the “XPages Machine” A deeper look at an XPages Request nlnotes.exe nhttp.exe OSGi Framework JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Understanding the “XPages Machine” A deeper look at an XPages Request nlnotes.exe nhttp.exe XPages Request Processing Lifecycle OSGi Framework JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Understanding the “XPages Machine” The XPages Request Processing Lifecycle Most typically executed for HTTP GET & POST Requests

Understanding the “XPages Machine” The XPages Request Processing Lifecycle GET = 1,6 Most typically executed for HTTP GET & POST Requests

Understanding the “XPages Machine” The XPages Request Processing Lifecycle POST = 1,2,3,4,5,6 GET = 1,6 Most typically executed for HTTP GET & POST Requests

Understanding the “XPages Machine” The XPages Request Processing Lifecycle POST = 1,2,3,4,5,6 GET = 1,6 Most typically executed for HTTP GET & POST Requests 2 x System Level Phases [ 1,6 ] Executed for most HTTP GET & POST Requests

Understanding the “XPages Machine” The XPages Request Processing Lifecycle POST = 1,2,3,4,5,6 GET = 1,6 Most typically executed for HTTP GET & POST Requests 2 x System Level Phases [ 1,6 ] Executed for most HTTP GET & POST Requests 4 x Application Level Phases [ 2,3,4,5 ] Executed for HTTP POST Requests

Understanding the “XPages Machine” The XPages Request Processing Lifecycle POST = 1,2,3,4,5,6 GET = 1,6 Most typically executed for HTTP GET & POST Requests 2 x System Level Phases [ 1,6 ] Executed for most HTTP GET & POST Requests 4 x Application Level Phases [ 2,3,4,5 ] Executed for HTTP POST Requests 4 x Event Pseudo-Phases [ 2,3,4,5 ] Executed for HTTP POST Requests

Understanding the “XPages Machine” The XPages Request Processing Lifecycle POST = 1,2,3,4,5,6 GET = 1,6 Most typically executed for HTTP GET & POST Requests Phase execution can be optimized per Request to lower Performance cost! 2 x System Level Phases [ 1,6 ] Executed for most HTTP GET & POST Requests 4 x Application Level Phases [ 2,3,4,5 ] Executed for HTTP POST Requests 4 x Event Pseudo-Phases [ 2,3,4,5 ] Executed for HTTP POST Requests

Understanding the “XPages Machine” The XPages Request Processing Lifecycle  Chp20Ed2.nsf is a testing harness from Mastering XPages, Second Edition, demonstrating a variety of XPages Request Processing Lifecycle use cases ─ Introduces Lifecycle phases and advanced use cases governed by the X-RPL ─ Uses a PhaseListener class to capture key phase entry / exit points – Allowing dynamic introspection of a request • See: DebugBeanPhaseListener.java faces-config.xml / index.xsp 41

Understanding the “XPages Machine” The XPages Request Processing Lifecycle  Chp20Ed2.nsf is a testing harness from Mastering XPages, Second Edition, demonstrating a variety of XPages Request Processing Lifecycle use cases ─ Introduces Lifecycle phases and advanced use cases governed by the X-RPL ─ Uses a PhaseListener class to capture key phase entry / exit points – Allowing dynamic introspection of a request • See: DebugBeanPhaseListener.java faces-config.xml / index.xsp 42

Understanding the “XPages Machine” The XPages Request Processing Lifecycle  Chp20Ed2.nsf is a testing harness from Mastering XPages, Second Edition, demonstrating a variety of XPages Request Processing Lifecycle use cases ─ Introduces Lifecycle phases and advanced use cases governed by the X-RPL ─ Uses a PhaseListener class to capture key phase entry / exit points – Allowing dynamic introspection of a request • See: DebugBeanPhaseListener.java faces-config.xml / index.xsp 43

Understanding the “XPages Machine” The XPages Request Processing Lifecycle  Chp20Ed2.nsf is a testing harness from Mastering XPages, Second Edition, demonstrating a variety of XPages Request Processing Lifecycle use cases Domino server console or Notes client OSGi console must be available to analyze details C:n1notes.exe "=C:n1notes.ini" -RPARAMS -console 44

Understanding the “XPages Machine” The XPages Request Processing Lifecycle  Chp20Ed2.nsf is a testing harness from Mastering XPages, Second Edition, demonstrating a variety of XPages Request Processing Lifecycle use cases Domino server console or Notes client OSGi console must be available to analyze details C:n1notes.exe "=C:n1notes.ini" -RPARAMS -console 45

Understanding the “XPages Machine” A deeper look at an XPages Request Key elements: XPages Request goes in… XPages Request Processing Lifecycle processes… XPages Request Introspection gives us insight into execution… XPages Response comes out!

Developing for Performance

Developing for Performance The XPages Toolbox  XPages based Application (The “XPages Swiss Army Knife”) – Runs on the Domino server or the Notes client – XPagesToolbox.nsf needs to be installed on the Domino server or XPiNC client – A profiler .jar file needs to be added to the JVM launch options & JVM java.policy updated  Should be used regularly during development / testing cycles to: – Profile CPU performance & Memory usage (per request or periodically) / Backend usage – Control logging of XPages Runtime loggers – View current Threads in the nhttp process – Create Java Heap Dumps / XML Memory Dumps – Production use only for problem resolution - sensitive data collection capabilities  Available from OpenNTF.org – Free open source project / Search for “XPages Toolbox” / Authored by Philippe Riand, IBM – Full readme.pdf instructions within the project download files

Developing for Performance The XPages Toolbox  XPages based Application (The “XPages Swiss Army Knife”) – Runs on the Domino server or the Notes client – XPagesToolbox.nsf needs to be installed on the Domino server or XPiNC client – A profiler .jar file needs to be added to the JVM launch options & JVM java.policy updated  Should be used regularly during development / testing cycles to: – Profile CPU performance & Memory usage (per request or periodically) / Backend usage – Control logging of XPages Runtime loggers – View current Threads in the nhttp process – Create Java Heap Dumps / XML Memory Dumps – Production use only for problem resolution - sensitive data collection capabilities  Available from OpenNTF.org – Free open source project / Search for “XPages Toolbox” / Authored by Philippe Riand, IBM – Full readme.pdf instructions within the project download files

Developing for Performance The XPages Toolbox  XPages based Application (The “XPages Swiss Army Knife”) – Runs on the Domino server or the Notes client – XPagesToolbox.nsf needs to be installed on the Domino server or XPiNC client – A profiler .jar file needs to be added to the JVM launch options & JVM java.policy updated  Should be used regularly during development / testing cycles to: – Profile CPU performance & Memory usage (per request or periodically) / Backend usage – Control logging of XPages Runtime loggers – View current Threads in the nhttp process – Create Java Heap Dumps / XML Memory Dumps – Production use only for problem resolution - sensitive data collection capabilities  Available from OpenNTF.org – Free open source project / Search for “XPages Toolbox” / Authored by Philippe Riand, IBM – Full readme.pdf instructions within the project download files

Developing for Performance Using the XPages Toolbox  Provides insight into CPU Time and Wall Time cost of a request – CPU Time is the amount of time spent by the CPU actually processing XPages code (ie: burning real CPU cycles) • No idle time included such as waiting on non-CPU intensive code – Wall Time is the amount of time spent actually processing XPages code and any idle time • Like watching the time going by on the “clock on the wall”

Developing for Performance Using the XPages Toolbox  Provides insight into CPU Time and Wall Time cost of a request – CPU Time is the amount of time spent by the CPU actually processing XPages code (ie: burning real CPU cycles) • No idle time included such as waiting on non-CPU intensive code – Wall Time is the amount of time spent actually processing XPages code and any idle time • Like watching the time going by on the “clock on the wall”

Developing for Performance Using the XPages Toolbox  Provides insight into CPU Time and Wall Time cost of a request – CPU Time is the amount of time spent by the CPU actually processing XPages code (ie: burning real CPU cycles) • No idle time included such as waiting on non-CPU intensive code – Wall Time is the amount of time spent actually processing XPages code and any idle time • Like watching the time going by on the “clock on the wall”

Developing for Performance Using the XPages Toolbox  Provides insight into custom SSJS code using Profile Blocks __profile(“blockIdentifier”, “optionalInformation”){ // profile my custom code... var nd:NotesDocument = document1.getDocument(); .... }

Developing for Performance Using the XPages Toolbox  Provides insight into custom SSJS code using Profile Blocks __profile(“blockIdentifier”, “optionalInformation”){ // profile my custom code... var nd:NotesDocument = document1.getDocument(); .... __profile(“blockIdentifier”, “optionalInformation”){ // profile my nested profile block... var x = nd.getItemValueString(“x”); .... } }

Developing for Performance Using the XPages Toolbox  Provides insight into custom Java code using Profile Block Decorator private static final ProfilerType pt = new ProfilerType("MyBlock"); public void myMethod() { if(Profiler.isEnabled()) { ProfilerAggregator pa = Profiler.startProfileBlock(pt, null); long startTime = Profiler.getCurrentTime(); try { _myMethod(); } finally { Profiler.endProfileBlock(pa, startTime); } } else { _myMethod(); } } private void _myMethod() { // real implementation of myMethod … }

Developing for Performance Using the XPages Toolbox  Provides insight into custom Java code using Profile Block Decorator private static final ProfilerType pt = new ProfilerType("MyBlock"); public void myMethod() { if(Profiler.isEnabled()) { ProfilerAggregator pa = Profiler.startProfileBlock(pt, null); long startTime = Profiler.getCurrentTime(); try { _myMethod(); } finally { Profiler.endProfileBlock(pa, startTime); } } else { _myMethod(); } } private void _myMethod() { // real implementation of myMethod … }

Developing for Performance Using the XPages Toolbox  Provides insight into custom Java code using Profile Block Decorator private static final ProfilerType pt = new ProfilerType("MyBlock"); public void myMethod() { if(Profiler.isEnabled()) { ProfilerAggregator pa = Profiler.startProfileBlock(pt, null); long startTime = Profiler.getCurrentTime(); try { _myMethod(); } finally { Profiler.endProfileBlock(pa, startTime); } } else { _myMethod(); } } private void _myMethod() { // real implementation of myMethod … }

Developing for Performance Using the XPages Toolbox  Provides insight into custom Java code using Profile Block Decorator private static final ProfilerType pt = new ProfilerType("MyBlock"); public void myMethod() { if(Profiler.isEnabled()) { ProfilerAggregator pa = Profiler.startProfileBlock(pt, null); long startTime = Profiler.getCurrentTime(); try { _myMethod(); } finally { Profiler.endProfileBlock(pa, startTime); } } else { _myMethod(); } } private void _myMethod() { // real implementation of myMethod … }

Developing for Performance Using the XPages Toolbox  Provides insight into custom Java code using Profile Block Decorator private static final ProfilerType pt = new ProfilerType("MyBlock"); public void myMethod() { if(Profiler.isEnabled()) { ProfilerAggregator pa = Profiler.startProfileBlock(pt, null); long startTime = Profiler.getCurrentTime(); try { _myMethod(); } finally { Profiler.endProfileBlock(pa, startTime); } } else { _myMethod(); } } private void _myMethod() { // real implementation of myMethod … }

Developing for Performance Using the XPages Toolbox  Provides insight into custom Java code using Profile Block Decorator private static final ProfilerType pt = new ProfilerType("MyBlock"); public void myMethod() { if(Profiler.isEnabled()) { ProfilerAggregator pa = Profiler.startProfileBlock(pt, null); long startTime = Profiler.getCurrentTime(); try { _myMethod(); } finally { Profiler.endProfileBlock(pa, startTime); } } else { _myMethod(); } } private void _myMethod() { // real implementation of myMethod … }

Developing for Performance Using the XPages Toolbox  Non-Invasive and Supportive – Leave the custom Profile Blocks in your SSJS / Java Code • No negative performance impact on any application even if the XPages Toolbox is not installed on a server or XPiNC client • Therefore supporting you for future profiling & maintenance tasks

Developing for Performance Using the XPages Toolbox  Non-Invasive and Supportive – Leave the custom Profile Blocks in your SSJS / Java Code • No negative performance impact on any application even if the XPages Toolbox is not installed on a server or XPiNC client • Therefore supporting you for future profiling & maintenance tasks

Developing for Performance Using the XPages Toolbox  Non-Invasive and Supportive – Leave the custom Profile Blocks in your SSJS / Java Code • No negative performance impact on any application even if the XPages Toolbox is not installed on a server or XPiNC client • Therefore supporting you for future profiling & maintenance tasks

Developing for Performance The XPages Toolbox Key elements: Profile XPages Request using Wall and CPU Profilers... Perform CPU and Wall time intensive tasks... Analyze profiling results and identify issues in the XPages Toolbox!

Developing for Performance A Lean, Mean “XPages Machine”!  Core things you need to leverage in order to reduce CPU processing (along with Memory usage to a lesser degree) relative to the workings of the X-RPL – Use Partial Refresh – Use Partial Execution – Use computed rendered properties with caution for “hideWhen” UI logic, instead prefer the loaded property under Complete Refresh – Use the Dynamic Content control for advanced “hideWhen” UI logic under Partial Refresh – See Mastering XPages, Second Edition, Chapter 20 Advanced Performance Topics, for in-depth explanation and worked examples related to the X-RPL

Developing for Performance A Lean, Mean “XPages Machine”!  Core things you need to leverage in order to reduce CPU processing (along with Memory usage to a lesser degree) relative to the workings of the X-RPL – Use Partial Refresh – Use Partial Execution – Use computed rendered properties with caution for “hideWhen” UI logic, instead prefer the loaded property under Complete Refresh – Use the Dynamic Content control for advanced “hideWhen” UI logic under Partial Refresh – See Mastering XPages, Second Edition, Chapter 20 Advanced Performance Topics, for in-depth explanation and worked examples related to the X-RPL Partial Refresh  Eliminates extra component tree processing in the RENDER_RESPONSE phase  Reduces the HTML response to just that of the target refresh area within the component tree Partial Execution  Eliminates extra component tree processing in the four “application” level phases  By default only the invoking event handler will be processed when no target execute area is specified

Developing for Performance A Lean, Mean “XPages Machine”!  Core things you need to leverage in order to reduce CPU processing (along with Memory usage to a lesser degree) relative to the workings of the X-RPL – Use Partial Refresh – Use Partial Execution rendered vs loaded  rendered is a special property used to determine which branches of a component tree should be processed during POST back and GET requests – Use computed rendered properties with caution for “hideWhen” UI logic, instead prefer the loaded property under Complete Refresh  It will be invoked up to four times during a POST back request so must be used sparingly or avoided – Use the Dynamic Content control for advanced “hideWhen” UI logic under Partial Refresh  loaded is an absolute property and only invoked during the initial Page Load event therefore requires a context.reloadPage() or Complete Refresh to reinvoke – See Mastering XPages, Second Edition, Chapter 20 Advanced Performance Topics, for in-depth explanation and worked examples related to the X-RPL

Developing for Performance A Lean, Mean “XPages Machine”!  Core things you need to leverage in order to reduce CPU processing (along with Memory usage to a lesser degree) relative to the workings of the X-RPL – Use Partial Refresh – Use Partial Execution Dynamic Content Control  This control dynamically loads and discards its child content in a highly optimised manner relative to the X-RPL “hideWhen” on steroids! – Use computed rendered properties with caution for “hideWhen” UI logic, instead prefer the loaded property under Complete Refresh  Partial Refresh requests can be issued against an instance within a component tree using a range of SSJS / CSJS methods – Use the Dynamic Content control for advanced “hideWhen” UI logic under Partial Refresh  It provides the ability to update the browser URL for bookmarking and back-button support of dynamically retrieved AJAX content – See Mastering XPages, Second Edition, Chapter 20 Advanced Performance Topics, for in-depth explanation and worked examples related to the X-RPL  It supports SEO Robot indexing

Developing for Performance A Lean, Mean “XPages Machine”!  Core things you need to leverage in order to reduce CPU processing (along with Memory usage to a lesser degree) relative to the workings of the X-RPL – Use Partial Refresh – Use Partial Execution – Use computed rendered properties with caution for “hideWhen” UI logic, instead prefer the loaded property under Complete Refresh – Use the Dynamic Content control for advanced “hideWhen” UI logic under Partial Refresh – See Mastering XPages, Second Edition, Chapter 20 Advanced Performance Topics, for in-depth explanation and worked examples related to the X-RPL Mastering XPages, 2nd Edition  Chapter 20 focuses on the lowlevel mechanics of the X-RPL relative to making “real” performance gains  In-depth explanation and practical study of both Partial Refresh and Partial Execution  Myths about computed rendered and loaded are busted to unveil the reality about these two properties  Includes the first truly detailed in-depth explanation and practical study of the Dynamic Content control

Architecting for Scalability

Architecting for Scalability Looking at an XPages request again... nlnotes.exe nhttp.exe OSGi Framework JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Architecting for Scalability Looking at an XPages request again... XPages Request Processing Lifecycle nlnotes.exe nhttp.exe OSGi Framework JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Architecting for Scalability Looking at an XPages request again... XPages Request Processing Lifecycle nlnotes.exe nhttp.exe Hardware Product Code OSGi Framework Design JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Architecting for Scalability Looking at an XPages request again... nlnotes.exe nhttp.exe OSGi Framework JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Architecting for Scalability Looking at an XPages request again... nlnotes.exe XPages State Management Layer nhttp.exe OSGi Framework JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Architecting for Scalability Looking at an XPages request again... nlnotes.exe nhttp.exe XPages State Management Layer Hardware Product Code OSGi Framework Design JavaServer Faces Framework X-RPL Process XLIB XPages Runtime State Management Layer XPages Extensions [OSGi Bundles] *.nsf XSP Component Trees Backend, C/C++ Services (NSF,NIF,etc), Database Layers NSF Applications [ Component Modules ]

Architecting for Scalability The XPages State Management Layer Manages creation / removal of application, session, and component tree objects

Architecting for Scalability The XPages State Management Layer Serializes / Deserializes Manages creation / removal of application, session, and component tree objects XPage State as end user interacts with application

Architecting for Scalability The XPages State Management Layer Serializes / Deserializes Manages creation / removal of application, session, and component tree objects XPage State as end user interacts with application Can be configured per application to use either RAM and/or Disk allocated memory space for component trees

Architecting for Scalability The XPages State Management Layer Serializes / Deserializes XPage State as end user Manages creation / removal interacts with application of application, session, and Can be configured component tree objects per application to use either RAM and/or Disk allocated memory space for component trees Manages memory usage on a LRU algorithm / maximum views configuration

Architecting for Scalability The XPages State Management Layer Serializes / Deserializes XPage State as end user Manages creation / removal interacts with application of application, session, and Can be configured component tree objects per application to use either RAM and/or Disk allocated memory space for component trees Can be configured per application to compress the Manages memory usage on serialized state of a a LRU algorithm / maximum component tree for views configuration disk storage

Architecting for Scalability The XPages State Management Layer Serializes / Deserializes XPage State as end user Manages creation / removal interacts with application of application, session, and Can be configured component tree objects per application to use either RAM and/or Disk allocated memory space for component trees Can be configured Can perform delta per application to level updates during serialization compress the Manages memory usage on serialized state of a a LRU algorithm / maximum component tree for views configuration disk storage

Architecting for Scalability The XPages State Management Layer – JVM Memory Structure  The XPages State Management Layer (X-SML) uses the Java Virtual Machine (JVM) and is governed by it's memory structure – Therefore so are your XPages applications!

Architecting for Scalability The XPages State Management Layer – JVM Memory Structure  The XPages State Management Layer (X-SML) uses the Java Virtual Machine (JVM) and is governed by it's memory structure – Therefore so are your XPages applications!

Architecting for Scalability The XPages State Management Layer – JVM Memory Structure  JVM Memory (aka Data Area) is divided into a number of segments – broadly divided like so: • Non-Heap Memory: Storage for loaded classes, constant members, method metadata, interned strings, internal JVM objects and structures, loaded profiler agent code and data, etc • Heap Memory: Storage for Java objects (actual instances of classes) from currently loaded applications

Architecting for Scalability The XPages State Management Layer – JVM Memory Structure  JVM Memory (aka Data Area) is divided into a number of segments – broadly divided like so: • Non-Heap Memory: Storage for loaded classes, constant members, method metadata, interned strings, internal JVM objects and structures, loaded profiler agent code and data, etc • Heap Memory: Storage for Java objects (actual instances of classes) from currently loaded applications

Architecting for Scalability The XPages State Management Layer – JVM Memory Structure  JVM Memory (aka Data Area) is divided into a number of segments – broadly divided like so: • Non-Heap Memory: Storage for loaded classes, constant members, method metadata, interned strings, internal JVM objects and structures, loaded profiler agent code and data, etc • Heap Memory: Storage for Java objects (actual instances of classes) from currently loaded applications

Architecting for Scalability The XPages State Management Layer – JVM Memory Structure  JVM Memory (aka Data Area) is divided into a number of segments – broadly divided like so: • Non-Heap Memory: Storage for loaded classes, constant members, method metadata, interned strings, internal JVM objects and structures, loaded profiler agent code and data, etc • Heap Memory: Storage for Java objects (actual instances of classes) from currently loaded applications HTTPJVMMaxHeapSize=256M HTTPJVMMaxHeapSizeSet=1

Architecting for Scalability The XPages State Management Layer – JVM Memory Structure  JVM Memory (aka Data Area) is divided into a number of segments – broadly divided like so: • Non-Heap Memory: Storage for loaded classes, constant members, method metadata, interned strings, internal JVM objects and structures, loaded profiler agent code and data, etc • Heap Memory: Storage for Java objects (actual instances of classes) from currently loaded applications RAM HTTPJVMMaxHeapSize=256M HTTPJVMMaxHeapSizeSet=1

Architecting 32 BitScalability for Operating System JVM Heap → The XPages State Management Layer – JVM Memory Structure  Limited to maximum 32bit address  Minus OS allocated RAM space  Therefore, maximum 32bit JVM Heap size is typically 1.5 Gb (depending on OS RAM size)  JVM Memory (aka Data Area) is divided into a number of segments – broadly divided like so:  Therefore, maximum JVM Heap size cannot exceed maximum 32bit address and the remaining available RAM space  An exception will typically be thrown if JVM Heap size is set > than available RAM RAM • Non-Heap Memory: Storage for loaded classes, constant members, method metadata, interned strings, internal JVM objects and structures, loaded profiler agent code and data, etc • Heap Memory: Storage for Java objects (actual instances of classes) from currently loaded applications HTTPJVMMaxHeapSize=256M HTTPJVMMaxHeapSizeSet=1

Architecting 32 BitScalability for Operating System JVM Heap → The XPages State Management Layer – JVM Memory Structure  Limited to maximum 32bit address  Minus OS allocated RAM space  Therefore, maximum 32bit JVM Heap size is typically 1.5 Gb (depending on OS RAM size)  JVM Memory (aka Data Area) is divided into a number of segments – Heap → 64 Bit Operating System JVM broadly divided like so:  Therefore, maximum JVM Heap size cannot exceed maximum 32bit address and the remaining available RAM space  An exception will typically be thrown if JVM Heap size is set > than available RAM RAM  Limited to maximum 64bit address which is • Non-Heap Memory: Storage for loaded infinitely larger than any available RAM classes, constant members, method metadata, interned strings, internal JVM objects  Minus OS allocated RAM space and OS limits – andWin7 Enterprise → profiler agent code ie: structures, loaded Max: 192Gb and data, etc  Therefore, maximum 64bit JVM Heap size can stretch far beyond 32bit 1.5Gb boundary • Heap Memory: Storage for Java objects (actual instances of classes) from currently  In fact, so large that JVM Heap size can be set > loaded applications than RAM as address spaces are still available – However, the system will start “paging” or “thrashing” which makes things very slow! HTTPJVMMaxHeapSize=256M size should ideally  So maximum 64bit JVM Heap be set somewhere up to maximum available RAM HTTPJVMMaxHeapSizeSet=1 size with consideration of all related factors

Architecting 32 BitScalability for Operating System JVM Heap → The XPages State Management Layer – JVM Memory Structure  Limited to maximum 32bit address  Minus OS allocated RAM space  Therefore, maximum 32bit JVM Heap size is typically 1.5 Gb (depending on OS RAM size)  JVM Memory (aka Data Area) is divided into a number of segments – Heap → 64 Bit Operating System JVM broadly divided like so:  Therefore, maximum JVM Heap size cannot exceed maximum 32bit address and the remaining available RAM space  An exception will typically be thrown if JVM Heap size is set > than available RAM RAM  Limited to maximum 64bit address which is • Non-Heap Memory: Storage for loaded infinitely larger than any available RAM classes, constant members, method metadata, interned strings, internal  Minus OS allocated RAM space JVM objects and structures, loaded profiler agent code  Therefore, maximum 64bit JVM Heap size can and data, etc stretch far beyond 32bit 1.5Gb boundary Heap large that JVM Heap size objects  In• fact, soMemory: Storage for Java can be set > (actual instances of classes) from spaces are than available RAM because address currently still loaded applications available – However, the system will start “paging” or “thrashing” which makes things very slow! HTTPJVMMaxHeapSize=256M size should ideally  So maximum 64bit JVM Heap be set somewhere up to maximum available RAM HTTPJVMMaxHeapSizeSet=1 size with consideration of all related factors

Architecting 32 BitScalability for Operating System JVM Heap → The XPages State Management “What is JVMbest JVM Heap Size?” Layer – the Memory Structure  Limited to maximum 32bit address  No  Minus OS allocated RAM space “silver bullet” can be commonly applied!  JVM Memory (aka Data Area) is divided into a number  Should size is of segments Heap → 64  Therefore, maximum 32bit JVM Heapbe calculated based upon–stakeholder Bit Operating System JVM broadly divided like so: expectations / requirements of an application / typically 1.5 Gb (depending on OS RAM size)  Limited to maximum 64bit address which is host system • Non-Heap Memory: Storage for loaded infinitely larger than any available RAM  Therefore, maximum JVM Heap size cannot classes, constant  Requires careful memory profiling and analysismembers, method metaexceed maximum 32bit address and the data, interned strings, internal  Minus OS allocated RAM space JVM objects into remaining available RAM space horizontal cost for different application loaded profiler agent code and structures, workflow use cases / request loads maximum 64bit JVM Heap size can  Therefore, and data, etc  An exception will typically be thrown if JVM Heap  Make the effort to correctstretch far beyond 32bit 1.5Gb boundary vertical and horizontal size is set > than available RAM cost issues as you develop fact, soMemory: Storage for Java can be set > test to ensure  In• / Heap large that JVM Heap size objects applications are as efficient asavailable RAM because address currently (actual instances of classes) from spaces are than possible! still loaded applications available – However, the system will start “paging” or “thrashing” which makes things very slow! RAM HTTPJVMMaxHeapSize=256M size should ideally  So maximum 64bit JVM Heap be set somewhere up to maximum available RAM HTTPJVMMaxHeapSizeSet=1 size with consideration of all related factors

Architecting for Scalability The XPages State Management Layer – Disk Persistence  Over and above JVM Heap space, the XPages State Management Layer is also able to make use of Hard Disk Drive space → aka Disk Persistence – Therefore expanding potential storage space for XPages state / component trees – For fully-optimised XPages applications and host systems this opens up “Big Data” scalability opportunities

Architecting for Scalability The XPages State Management Layer – Disk Persistence  Over and above JVM Heap space, the XPages State Management Layer is also able to make use of Hard Disk Drive space → aka Disk Persistence – Therefore expanding potential storage space for XPages state / component trees – For fully-optimised XPages applications and host systems this opens up “Big Data” scalability opportunities

Architecting for Scalability The XPages State Management Layer – Disk Persistence  Over and above JVM Heap space, the XPages State Management Layer is also able to make use of Hard Disk Drive space → aka Disk Persistence – Therefore expanding potential storage space for XPages state / component trees – For fully-optimised XPages applications and host systems this opens up “Big Data” scalability opportunities

Architecting for Scalability The XPages State Management Layer – Persistence Options  The XPages Runtime and individual XPages applications be configured to use the Persistence options per requirements – RAM Persistence exclusively – Disk Persistence exclusively (default) – RAM and Disk Persistence together

Architecting for Scalability The XPages State Management Layer – Persistence Options  The XPages Runtime and individual XPages applications be configured to use the Persistence options per requirements – RAM Persistence exclusively – Disk Persistence exclusively (default) – RAM and Disk Persistence together

Architecting for Scalability The XPages State Management Layer – Persistence Options  The XPages Runtime and individual XPages applications be configured to use the Persistence options per requirements – RAM Persistence exclusively – Disk Persistence exclusively (default) – RAM and Disk Persistence together

Architecting for Scalability The XPages State Management Layer – Persistence Options  The XPages Runtime and individual XPages applications be configured to use the Persistence options per requirements – RAM Persistence exclusively – Disk Persistence exclusively (default) – RAM and Disk Persistence together

Architecting for Scalability The XPages State Management Layer – xsp.properties  A range of xsp.properties can be used to configure / tune the XPages State Management Layer at global runtime and/or per application level  xsp.persistence.mode – basic → “Keep pages in memory” – file → “Keep pages on disk” (default) – fileex → “Keep only the current page in memory”  xsp.persistence.viewstate – fulltree → Entire tree and state persisted (default) (RAM and Disk) – nostate → No tree or state persisted (RAM and Disk) – delta → Initial tree and updates to state after (RAM only) – deltaex → No tree but only state (RAM only)  xsp.persistence.tree.maxviews (default: 4)  xsp.persistence.file.maxviews (default: 16)

Architecting for Scalability The XPages State Management Layer – xsp.properties  A range of xsp.properties can be used to configure / tune the XPages State Management Layer at global runtime and/or per application level – xsp.persistence.file.gzip (default: false) – xsp.persistence.file.threshold (default: 0) – xsp.persistence.file.async (default: true) – xsp.persistence.dir.xspstate (default: XSP State Directory) → Global Only – xsp.application.timeout (default: 30) – xsp.session.timeout (default: 30) – xsp.session.transient (default: false)  Note: Changes to any of these requires a HTTP task or Server restart

Architecting for Scalability The XPages State Management Layer – Persistence Options “Keep pages in memory” – Enables faster request processing as no Disk I/O is involved to create / read / write XPages component trees – Uses RAM space quicker and more intensely therefore lowrange scalability is only possible

Architecting for Scalability The XPages State Management Layer – Persistence Options “Keep pages in memory” – Enables faster request processing as no Disk I/O is involved to create / read / write XPages component trees – Uses RAM space quicker and more intensely therefore lowrange scalability is only possible

Architecting for Scalability The XPages State Management Layer – Persistence Options “Keep pages on disk” – Slightly slower processing as Disk I/O is involved to create / read / write XPage component trees to/from Disk – All XPage component trees are persisted to Disk storage therefore maximising potential scalability

Architecting for Scalability The XPages State Management Layer – Persistence Options “Keep pages on disk” – Slightly slower processing as Disk I/O is involved to create / read / write XPage component trees to/from Disk – All XPage component trees are persisted to Disk storage therefore maximising potential scalability

Architecting for Scalability The XPages State Management Layer – Persistence Options “Keep only the current page in memory” – Enables faster request processing against the currently viewed XPage as no Disk I/O is involved but other component trees involve Disk I/O as user navigates around an application – Uses RAM relative to #users and XPages being viewed / sizeof, so mid-range scalability is possible

Architecting for Scalability The XPages State Management Layer – Persistence Options “Keep only the current page in memory” – Enables faster request processing against the currently viewed XPage as no Disk I/O is involved but other component trees involve Disk I/O as user navigates around an application – Uses RAM relative to #users and XPages being viewed / sizeof, so mid-range scalability is possible

Architecting for Scalability The XPages State Management Layer – Persistence Options “No State” – Option to bypass RAM/Disk Persistence can be set at XPages Runtime level, per application level, or individual XPage level • xsp.property / viewState – “stateless” so only use for pure read only type XPages • No viewScope, ..., etc

Architecting for Scalability The XPages State Management Layer – Persistence Options “No State” – Option to bypass RAM/Disk Persistence can be set at XPages Runtime level, per application level, or individual XPage level • xsp.property / viewState – “stateless” so only use for pure read only type XPages • No viewScope, ..., etc

Architecting for Scalability Surface Zero - Analysing Memory Usage CPU, Wall Time, and Backend profiling gives insight into the vertical processing costs for any given XPage request

Architecting for Scalability Surface Zero - Analysing Memory Usage CPU, Wall Time, and Backend profiling gives insight into the vertical processing costs for any given XPage request But what about vertical and horizontal memory costs?

Architecting for Scalability Surface Zero - Analysing Memory Usage CPU, Wall Time, and Backend profiling gives insight into the vertical processing costs for any given XPage request But what about vertical and horizontal memory costs? Analyze using JVM Heap Dumps

Architecting for Scalability Surface Zero - Analysing Memory Usage CPU, Wall Time, and Backend profiling gives insight into the vertical processing costs for any given XPage request But what about vertical and horizontal memory costs? Analyze using JVM Heap Dumps Analyze using JVM System Dumps

Architecting for Scalability Surface Zero - Analysing Memory Usage CPU, Wall Time, and Backend profiling gives insight into the vertical processing costs for any given XPage request But what about vertical and horizontal memory costs? Analyze using JVM Heap Dumps Analyze using JVM System Dumps Analyze using XML Session Dumps

Architecting for Scalability Analysing Memory Usage – JVM Heap & System Dumps  Generate a JVM Heap or System Dump of the HTTP task JVM memory – A button in the XPages Toolbox generates a JVM Heap Dump – XSP Commands on the Domino Server console allow spontaneous Heap / System Dump creation • tell http xsp heapdump (triggers com.ibm.jvm.Dump.HeapDump()) • tell http xsp systemdump (triggers com.ibm.jvm.Dump.SystemDump())  Analyze Heap / System Dumps using the Eclipse Memory Analyzer – http://www.eclipse.org/mat/ – Also install Eclipse Extension: IBM Diagnostic Tool Framework for Java Version 1.1 http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html  Heap Dumps automatically occur in production when certain conditions occur – Eg: By default when an XPage fails due to the server running out of JVM Memory • java.lang.OutOfMemoryError

Architecting for Scalability Analysing Memory Usage – JVM Heap & System Dumps  Generate a JVM Heap or System Dump of the HTTP task JVM memory – A button in the XPages Toolbox generates a JVM Heap Dump – XSP Commands on the Domino Server console allow spontaneous Heap / System Dump creation • tell http xsp heapdump (triggers com.ibm.jvm.Dump.HeapDump()) • tell http xsp systemdump (triggers com.ibm.jvm.Dump.SystemDump())  Analyze Heap / System Dumps using the Eclipse Memory Analyzer – http://www.eclipse.org/mat/ – Also install Eclipse Extension: IBM Diagnostic Tool Framework for Java Version 1.1 http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html  Heap Dumps automatically occur in production when certain conditions occur – Eg: By default when an XPage fails due to the server running out of JVM Memory • java.lang.OutOfMemoryError

Architecting for Scalability Analysing Memory Usage – JVM Heap & System Dumps  Generate a JVM Heap or System Dump of the HTTP task JVM memory – A button in the XPages Toolbox generates a JVM Heap Dump – XSP Commands on the Domino Server console allow spontaneous Heap / System Dump creation • tell http xsp heapdump (triggers com.ibm.jvm.Dump.HeapDump()) • tell http xsp systemdump (triggers com.ibm.jvm.Dump.SystemDump())  Analyze Heap / System Dumps using the Eclipse Memory Analyzer – http://www.eclipse.org/mat/ – Also install Eclipse Extension: IBM Diagnostic Tool Framework for Java Version 1.1 http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html  Heap Dumps automatically occur in production when certain conditions occur – Eg: By default when an XPage fails due to the server running out of JVM Memory • java.lang.OutOfMemoryError

Architecting for Scalability Analysing Memory Usage – XML Session Dumps  Generate XML Session Dumps of the HTTP task JVM memory – Two options available under the XPages Toolbox → Session Dumps Tab Full XML Session Dump Partial XML Session Dump  Analyze XML Session Dumps using a Browser, or any XML/Text Editor – Caution required on production systems as sensitive data is collected within the XML Session Dump file

Architecting for Scalability Analysing Memory Usage – XML Session Dumps  Generate XML Session Dumps of the HTTP task JVM memory – Two options available under the XPages Toolbox → Session Dumps Tab Full XML Session Dump Partial XML Session Dump  Analyze XML Session Dumps using a Browser, or any XML/Text Editor – Caution required on production systems as sensitive data is collected within the XML Session Dump file

Architecting for Scalability Heap/System/XML Session Dumps Key elements: Make XPages Requests... Generate Heap/System/XML Session Dumps... Analyze memory usage in each type of Dump format to identify issues!

Architecting for Scalability Heap/System Dumps – OQL / Navigating XSP Objects Entry Point... (1) x Application → (1) x NSFComponentModule com.ibm.domino.xsp.module.nsf.NSFComponentModule “Keep pages in memory” java.util.HashMap (1) x NSFComponentModule → (M) x LCDAdapterHttpSession com.ibm.designer.runtime.domino.adapter.servlet.LCDAdapterHttpSession java.util.Hashtable (1) x LCDAdapterHttpSession → (1) x $ViewHolder com.ibm.xsp.application.BasicStateManagerImpl$ViewHolder Object containing RAM Persistence component trees (4) (1) x $ViewHolder → (M[4]) x $PageEntry com.ibm.xsp.application.BasicStateManagerImpl$ViewHolder$PageEntry (1) x $PageEntry → (1) x UIViewRootEx2 com.ibm.xsp.component.UIViewRootEx2 (1) x UIViewRootEx2 → viewScope, etc javax.faces.component.UIViewRoot$ViewMap

Architecting for Scalability Heap/System Dumps – OQL / Navigating XSP Objects Entry Point... (1) x Application → (1) x NSFComponentModule com.ibm.domino.xsp.module.nsf.NSFComponentModule “Keep current page in memory” java.util.HashMap (1) x NSFComponentModule → (M) x LCDAdapterHttpSession com.ibm.designer.runtime.domino.adapter.servlet.LCDAdapterHttpSession java.util.Hashtable (1) x LCDAdapterHttpSession → (1) x $SessionState com.ibm.xsp.application.FileStateManager$SessionState (1) x $SessionState → (M[16]) x $ViewState com.ibm.xsp.application.FileStateManager$ViewState[16] (1) x $PageEntry → (1) x UIViewRootEx2 com.ibm.xsp.component.UIViewRootEx2 (1) x UIViewRootEx2 → viewScope, etc javax.faces.component.UIViewRoot$ViewMap Reference object to Disk Persistence component trees (16) Object containing current RAM Persistence component tree (1)

Architecting for Scalability Heap/System Dumps – OQL / Navigating XSP Objects Entry Point... (1) x Application → (1) x NSFComponentModule com.ibm.domino.xsp.module.nsf.NSFComponentModule “Keep pages on disk” java.util.HashMap (1) x NSFComponentModule → (M) x LCDAdapterHttpSession com.ibm.designer.runtime.domino.adapter.servlet.LCDAdapterHttpSession java.util.Hashtable (1) x LCDAdapterHttpSession → (1) x $SessionState com.ibm.xsp.application.FileStateManager$SessionState (1) x $SessionState → (M[16]) x $ViewState com.ibm.xsp.application.FileStateManager$ViewState[16] (1) x $ViewState → (1) x File com.ibm.xsp.application.FileStateManager$ViewState java.io.File Component tree state serialized in disk *.ser file Reference object to Disk Persistence component trees (16)

Architecting for Scalability Moving to the “X” Level!  Fundamentals for reducing RAM usage (and CPU processing) and enabling support for Disk Persistence relative to the X-SML – Ensure X-RPL vertical cost is as low as possible – Make Java/Beans implement java.io.Serializable – Avoid buffering SSJS Objects/Functions into viewScope – Apply Minimum Hold with low Application/Session timeouts – Only use Gzip compression for Disk Persistence after careful CPU and contention profiling of the Host System – See Mastering XPages, Second Edition, Chapter 20 Advanced Performance Topics, for in-depth explanation and worked examples related to the X-SML

Architecting for Scalability Moving to the “X” Level!  Fundamentals for reducing RAM usage (and CPU processing) and enabling support for Disk Persistence relative to the X-SML – Ensure X-RPL

#users presentations

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

XPages Masterclass: Scalability ibm xpages application ...

XPages Masterclass: Scalability tonymcguckin I’ve recently returned from IBM Connect 2014 in Orlando, Florida where I presented a two hour ...
Read more

Tip from IBM Connect 2014: Masterclass: XPages Scalability

This tip is from the IBM Connect 2014 session "JMP401: Masterclass: XPages Scalability". This tip specifically deals with developing XPages performance ...
Read more

using namespace XSP; | Tony McGuckin on engineering usable ...

using namespace XSP; ... Florida where I presented a two hour masterclass session on XPages Scalability (JMP401: Masterclass: XPages Scalability
Read more

Ad109 - XPages Performance and Scalability - Technology

JMP401: Masterclass: XPages Scalability. XPages Performance. Performance and Scalability Class Ppt. Exploring Scalability, Performance And Deployment.
Read more

Connections Developers | App Dev Presentations from IBM ...

App Dev Presentations from IBM Connect 2014 on Slideshare. Niklas Heidloff / February 11, ... AD503: XPages Mobile Development in IBM Domino 9.0.1 and beyond
Read more

Xpages | LinkedIn

View 2774 Xpages posts, presentations, experts, and more. Get the professional knowledge you need on LinkedIn.
Read more

Scalability | LinkedIn

View 221453 Scalability posts, presentations, experts, and more. Get the professional knowledge you need on LinkedIn.
Read more