SlideShare a Scribd company logo

JMP401: Masterclass: XPages Scalability

•
•
Tony McGuckin
Tony McGuckin

IBM Connect 2014: JMP401: Masterclass: XPages Scalability

Technology
1 of 158
Download to read offline
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 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 Low vertical cost precondition  Maximum Scalability potential will not be possible if there are underlying vertical cost issues still to be rectified
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 Serialization  More detail coming up...
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 Serialization  More detail coming up...
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 Minimum Hold  Application and Session timeout durations default to 30 minutes. Try to maintain these values or lower. Increasing these values increases horizontal cost!
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 time-outs – 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 Gzip Compression  Only use this option after careful analysis of the Host System behaviour under upper limit work load as it CPU intensive
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 time-outs – 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 Mastering XPages, 2nd Edition  Chapter 20 focuses on the mechanics of the X-SML relative to enabling an application to scale well  In-depth explanation and practical study of RAM and Disk Persistence options  Explains memory analysis using the Eclipse Memory Analyser and XPages Toolbox Session Dumps with practical study
Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – Custom Java / Managed Beans must implement the java.io.Serializable interface otherwise a java.io.NotSerializableException will be thrown when trying to use Disk Persistence! – Other Java pointers... • Use the transient modifier for unserializable or internally cached/calculated members → to reduce serialized footprint / avoid exceptions / reduce processing • Minimise duplicate Strings → consider shared constants / instances • Avoid initialising large empty HashMaps → consider lazyloading where possible
Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – Custom Java / Managed Beans must implement the java.io.Serializable interface otherwise a java.io.NotSerializableException will be thrown when trying to use Disk Persistence! – Other Java pointers... • Use the transient modifier for unserializable or internally cached/calculated members → to reduce serialized footprint / avoid exceptions / reduce processing • Minimise duplicate Strings → consider shared constants / instances • Avoid initialising large empty HashMaps → consider lazyloading where possible
Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – Custom Java / Managed Beans must implement the java.io.Serializable interface otherwise a java.io.NotSerializableException will be thrown when trying to use Disk Persistence! – Other Java pointers... • Use the transient modifier for unserializable or internally cached/calculated members → to reduce serialized footprint / avoid exceptions / reduce processing • Minimise duplicate Strings → consider shared constants / instances • Avoid initialising large empty HashMaps → consider lazyloading where possible
Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – ServerSide JavaScript (SSJS) Objects/Functions cannot be serialized into the viewScope variable when using Disk Persistence otherwise a java.io.NotSerializableException will be thrown! – If your business logic involves buffering SSJS Objects/Functions into the viewScope variable and scalability is important → consider porting into serializable Managed Beans to gain the benefits of Disk Persistence
Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – ServerSide JavaScript (SSJS) Objects/Functions cannot be serialized into the viewScope variable when using Disk Persistence otherwise a java.io.NotSerializableException will be thrown! – If your business logic involves buffering SSJS Objects/Functions into the viewScope variable and scalability is important → consider porting into serializable Managed Beans to gain the benefits of Disk Persistence
Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – ServerSide JavaScript (SSJS) Objects/Functions cannot be serialized into the viewScope variable when using Disk Persistence otherwise a java.io.NotSerializableException will be thrown! – If your business logic involves buffering SSJS Objects/Functions into the viewScope variable and scalability is important → consider porting into serializable Managed Beans to gain the benefits of Disk Persistence
Architecting for Scalability  You should now understand the demands placed upon a Host System by the “XPages Machine”  You also have seen how to gain insight into the vertical and horizontal costs by using the XPages Toolbox and Eclipse Memory Analyzer
Architecting for Scalability  You should now understand the demands placed upon a Host System by the “XPages Machine”  You also have seen how to gain insight into the vertical and horizontal costs by using the XPages Toolbox and Eclipse Memory Analyzer
Architecting for Scalability  You should now understand the demands placed upon a Host System by the “XPages Machine”  You also have seen how to gain insight into the vertical and horizontal costs by using the XPages Toolbox and Eclipse Memory Analyzer So how can you determine if a Host System has the potential to cope with the scalability demands of a given application and request load?
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  You should also consider using a dedicated Performance and Scalability automation testing tool to mimic “real” concurrent user work loads / network conditions / etc – IBM Rational Performance Tester http://www-03.ibm.com/software/products/en/performance/ – The Grinder http://grinder.sourceforge.net/  Note: The automation tool should reside on a separate “test” machine – not on the actual source application server otherwise profiling and analysis results will be distorted!
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  You should also consider using a dedicated Performance and Scalability automation testing tool to mimic “real” concurrent user work loads / network conditions / etc – IBM Rational Performance Tester http://www-03.ibm.com/software/products/en/performance/ – The Grinder http://grinder.sourceforge.net/  Note: The automation tool should reside on a separate “test” machine – not on the actual source application server otherwise profiling and analysis results will be distorted!
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example Equation V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H =: V . R P =: C / H If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example for Memory (Underload) V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H(300Mb) =: V(1mb) . R(300 users) P(3.41) =: C(1Gb) / H(300Mb) If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example for Memory (Maximum) V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H(1000Mb) =: V(1mb) . R(1000 users) P(1) =: C(1000Mb) / H(1000Mb) If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example for Memory (Overload) V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H(4000Mb) =: V(8Mb) . R(500 users) P(0.77) =: C(3Gb) / H(4000Mb) If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis Test Case: XPages Insights Into Big Data
Architecting for Scalability XPages Vertical/Horizontal Cost Analysis Host System  WIN7 Professional 64bit  24Gb RAM  Intel CORE i7 vPro 8 x CPU  448Gb HDD  Domino 9.0.1 64bit – JVM Heap: 10Gb
Q&A 154
155
 Access Connect Online to complete your session surveys using any: – Web or mobile browser – Connect Online kiosk onsite
Engage Online  SocialBiz User Group socialbizug.org – Join the epicenter of Notes and Collaboration user groups  Follow us on Twitter – @IBMConnect and @IBMSocialBiz  LinkedIn http://bit.ly/SBComm – Participate in the IBM Social Business group on LinkedIn:  Facebook https://www.facebook.com/IBMSocialBiz – Like IBM Social Business on Facebook  Social Business Insights blog ibm.com/blogs/socialbusiness – Read and engage with our bloggers
Acknowledgements and Disclaimers Availability. References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. © Copyright IBM Corporation 2014. All rights reserved.  U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.  IBM, the IBM logo, ibm.com, Notes, Domino, and XPages are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml Other company, product, or service names may be trademarks or service marks of others.

Recommended

JMP402 Master Class: Managed beans and XPages: Your Time Is Now
JMP402 Master Class: Managed beans and XPages: Your Time Is NowJMP402 Master Class: Managed beans and XPages: Your Time Is Now
JMP402 Master Class: Managed beans and XPages: Your Time Is NowRussell Maher
 
IBM Connect 2016 - AD1548 - Building Responsive XPages Applications
IBM Connect 2016 - AD1548 - Building Responsive XPages ApplicationsIBM Connect 2016 - AD1548 - Building Responsive XPages Applications
IBM Connect 2016 - AD1548 - Building Responsive XPages Applicationsbeglee
 
Building Responsive Applications Using XPages
Building Responsive Applications Using XPagesBuilding Responsive Applications Using XPages
Building Responsive Applications Using XPagesTeamstudio
 
BP204 It's Not Infernal: Dante's Nine Circles of XPages Heaven
BP204 It's Not Infernal: Dante's Nine Circles of XPages HeavenBP204 It's Not Infernal: Dante's Nine Circles of XPages Heaven
BP204 It's Not Infernal: Dante's Nine Circles of XPages HeavenMichael McGarel
 
Ask the XPages Experts
Ask the XPages ExpertsAsk the XPages Experts
Ask the XPages ExpertsTeamstudio
 
Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!
Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!
Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!Serdar Basegmez
 
Tips for Building your First XPages Java Application
Tips for Building your First XPages Java ApplicationTips for Building your First XPages Java Application
Tips for Building your First XPages Java ApplicationTeamstudio
 
How To Build a Multi-Field Search Page For Your XPages Application
How To Build a Multi-Field Search Page For Your XPages ApplicationHow To Build a Multi-Field Search Page For Your XPages Application
How To Build a Multi-Field Search Page For Your XPages ApplicationMichael McGarel
 

Recommended

JMP402 Master Class: Managed beans and XPages: Your Time Is Now
JMP402 Master Class: Managed beans and XPages: Your Time Is NowJMP402 Master Class: Managed beans and XPages: Your Time Is Now
JMP402 Master Class: Managed beans and XPages: Your Time Is NowRussell Maher
 
IBM Connect 2016 - AD1548 - Building Responsive XPages Applications
IBM Connect 2016 - AD1548 - Building Responsive XPages ApplicationsIBM Connect 2016 - AD1548 - Building Responsive XPages Applications
IBM Connect 2016 - AD1548 - Building Responsive XPages Applicationsbeglee
 
Building Responsive Applications Using XPages
Building Responsive Applications Using XPagesBuilding Responsive Applications Using XPages
Building Responsive Applications Using XPagesTeamstudio
 
BP204 It's Not Infernal: Dante's Nine Circles of XPages Heaven
BP204 It's Not Infernal: Dante's Nine Circles of XPages HeavenBP204 It's Not Infernal: Dante's Nine Circles of XPages Heaven
BP204 It's Not Infernal: Dante's Nine Circles of XPages HeavenMichael McGarel
 
Ask the XPages Experts
Ask the XPages ExpertsAsk the XPages Experts
Ask the XPages ExpertsTeamstudio
 
Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!
Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!
Engage 2015 - 10 Mistakes You and Every XPages Developer Make. Yes, I said YOU!Serdar Basegmez
 
Tips for Building your First XPages Java Application
Tips for Building your First XPages Java ApplicationTips for Building your First XPages Java Application
Tips for Building your First XPages Java ApplicationTeamstudio
 
How To Build a Multi-Field Search Page For Your XPages Application
How To Build a Multi-Field Search Page For Your XPages ApplicationHow To Build a Multi-Field Search Page For Your XPages Application
How To Build a Multi-Field Search Page For Your XPages ApplicationMichael McGarel
 
La vita nella corsia di sorpasso; A tutta velocità, XPages!
La vita nella corsia di sorpasso; A tutta velocità, XPages!La vita nella corsia di sorpasso; A tutta velocità, XPages!
La vita nella corsia di sorpasso; A tutta velocità, XPages!Ulrich Krause
 
Here Be Dragons - Debugging WordPress
Here Be Dragons - Debugging WordPressHere Be Dragons - Debugging WordPress
Here Be Dragons - Debugging WordPressRami Sayar
 
VMworld 2013: vCenter Deep Dive
VMworld 2013: vCenter Deep Dive VMworld 2013: vCenter Deep Dive
VMworld 2013: vCenter Deep Dive VMworld
 
PowerCLI Workshop
PowerCLI WorkshopPowerCLI Workshop
PowerCLI WorkshopCarter Shanklin
 
Piecing Together the WordPress Puzzle
Piecing Together the WordPress PuzzlePiecing Together the WordPress Puzzle
Piecing Together the WordPress PuzzleBusiness Vitality LLC
 
Speeding up your WordPress Site - WordCamp Toronto 2015
Speeding up your WordPress Site - WordCamp Toronto 2015Speeding up your WordPress Site - WordCamp Toronto 2015
Speeding up your WordPress Site - WordCamp Toronto 2015Alan Lok
 
XPages Mobile, #dd13
XPages Mobile, #dd13XPages Mobile, #dd13
XPages Mobile, #dd13Dominopoint - Italian Lotus User Group
 
XPages Workshop: Customizing OneUI
XPages Workshop: Customizing OneUIXPages Workshop: Customizing OneUI
XPages Workshop: Customizing OneUIMichael McGarel
 
Hybrid Mobile Development with Apache Cordova and
Hybrid Mobile Development with Apache Cordova and Hybrid Mobile Development with Apache Cordova and
Hybrid Mobile Development with Apache Cordova and Ryan Cuprak
 
Mobile Hybrid Development with WordPress
Mobile Hybrid Development with WordPressMobile Hybrid Development with WordPress
Mobile Hybrid Development with WordPressDanilo Ercoli
 
WordPress Development Tools and Best Practices
WordPress Development Tools and Best PracticesWordPress Development Tools and Best Practices
WordPress Development Tools and Best PracticesDanilo Ercoli
 
Improve WordPress performance with caching and deferred execution of code
Improve WordPress performance with caching and deferred execution of codeImprove WordPress performance with caching and deferred execution of code
Improve WordPress performance with caching and deferred execution of codeDanilo Ercoli
 
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...ddrschiw
 
Naked and afraid Offline Mobile
Naked and afraid Offline MobileNaked and afraid Offline Mobile
Naked and afraid Offline MobileColdFusionConference
 
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.WO Community
 
[English version] JavaFX and Web Integration
[English version] JavaFX and Web Integration[English version] JavaFX and Web Integration
[English version] JavaFX and Web IntegrationKazuchika Sekiya
 
Better Front-end Development in Atlassian Plugins
Better Front-end Development in Atlassian PluginsBetter Front-end Development in Atlassian Plugins
Better Front-end Development in Atlassian PluginsWojciech Seliga
 
High Performance JavaScript - Fronteers 2010
High Performance JavaScript - Fronteers 2010High Performance JavaScript - Fronteers 2010
High Performance JavaScript - Fronteers 2010Nicholas Zakas
 
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012Atlassian
 
Ajax basics
Ajax basicsAjax basics
Ajax basicsamanrahulraj
 
Camunda BPM 7.2: Performance and Scalability (English)
Camunda BPM 7.2: Performance and Scalability (English)Camunda BPM 7.2: Performance and Scalability (English)
Camunda BPM 7.2: Performance and Scalability (English)camunda services GmbH
 
Impact 2014 - IIB - selecting the right transformation option
Impact 2014 - IIB - selecting the right transformation optionImpact 2014 - IIB - selecting the right transformation option
Impact 2014 - IIB - selecting the right transformation optionAndrew Coleman
 

More Related Content

What's hot

La vita nella corsia di sorpasso; A tutta velocità, XPages!
La vita nella corsia di sorpasso; A tutta velocità, XPages!La vita nella corsia di sorpasso; A tutta velocità, XPages!
La vita nella corsia di sorpasso; A tutta velocità, XPages!Ulrich Krause
 
Here Be Dragons - Debugging WordPress
Here Be Dragons - Debugging WordPressHere Be Dragons - Debugging WordPress
Here Be Dragons - Debugging WordPressRami Sayar
 
VMworld 2013: vCenter Deep Dive
VMworld 2013: vCenter Deep Dive VMworld 2013: vCenter Deep Dive
VMworld 2013: vCenter Deep Dive VMworld
 
Piecing Together the WordPress Puzzle
Piecing Together the WordPress PuzzlePiecing Together the WordPress Puzzle
Piecing Together the WordPress PuzzleBusiness Vitality LLC
 
Speeding up your WordPress Site - WordCamp Toronto 2015
Speeding up your WordPress Site - WordCamp Toronto 2015Speeding up your WordPress Site - WordCamp Toronto 2015
Speeding up your WordPress Site - WordCamp Toronto 2015Alan Lok
 
XPages Workshop: Customizing OneUI
XPages Workshop: Customizing OneUIXPages Workshop: Customizing OneUI
XPages Workshop: Customizing OneUIMichael McGarel
 
Hybrid Mobile Development with Apache Cordova and
Hybrid Mobile Development with Apache Cordova and Hybrid Mobile Development with Apache Cordova and
Hybrid Mobile Development with Apache Cordova and Ryan Cuprak
 
Mobile Hybrid Development with WordPress
Mobile Hybrid Development with WordPressMobile Hybrid Development with WordPress
Mobile Hybrid Development with WordPressDanilo Ercoli
 
WordPress Development Tools and Best Practices
WordPress Development Tools and Best PracticesWordPress Development Tools and Best Practices
WordPress Development Tools and Best PracticesDanilo Ercoli
 
Improve WordPress performance with caching and deferred execution of code
Improve WordPress performance with caching and deferred execution of codeImprove WordPress performance with caching and deferred execution of code
Improve WordPress performance with caching and deferred execution of codeDanilo Ercoli
 
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...ddrschiw
 
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.WO Community
 
[English version] JavaFX and Web Integration
[English version] JavaFX and Web Integration[English version] JavaFX and Web Integration
[English version] JavaFX and Web IntegrationKazuchika Sekiya
 
Better Front-end Development in Atlassian Plugins
Better Front-end Development in Atlassian PluginsBetter Front-end Development in Atlassian Plugins
Better Front-end Development in Atlassian PluginsWojciech Seliga
 
High Performance JavaScript - Fronteers 2010
High Performance JavaScript - Fronteers 2010High Performance JavaScript - Fronteers 2010
High Performance JavaScript - Fronteers 2010Nicholas Zakas
 
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012Atlassian
 

What's hot (20)

La vita nella corsia di sorpasso; A tutta velocità, XPages!
La vita nella corsia di sorpasso; A tutta velocità, XPages!La vita nella corsia di sorpasso; A tutta velocità, XPages!
La vita nella corsia di sorpasso; A tutta velocità, XPages!
 
Here Be Dragons - Debugging WordPress
Here Be Dragons - Debugging WordPressHere Be Dragons - Debugging WordPress
Here Be Dragons - Debugging WordPress
 
VMworld 2013: vCenter Deep Dive
VMworld 2013: vCenter Deep Dive VMworld 2013: vCenter Deep Dive
VMworld 2013: vCenter Deep Dive
 
PowerCLI Workshop
PowerCLI WorkshopPowerCLI Workshop
PowerCLI Workshop
 
Piecing Together the WordPress Puzzle
Piecing Together the WordPress PuzzlePiecing Together the WordPress Puzzle
Piecing Together the WordPress Puzzle
 
Speeding up your WordPress Site - WordCamp Toronto 2015
Speeding up your WordPress Site - WordCamp Toronto 2015Speeding up your WordPress Site - WordCamp Toronto 2015
Speeding up your WordPress Site - WordCamp Toronto 2015
 
XPages Mobile, #dd13
XPages Mobile, #dd13XPages Mobile, #dd13
XPages Mobile, #dd13
 
XPages Workshop: Customizing OneUI
XPages Workshop: Customizing OneUIXPages Workshop: Customizing OneUI
XPages Workshop: Customizing OneUI
 
Hybrid Mobile Development with Apache Cordova and
Hybrid Mobile Development with Apache Cordova and Hybrid Mobile Development with Apache Cordova and
Hybrid Mobile Development with Apache Cordova and
 
Mobile Hybrid Development with WordPress
Mobile Hybrid Development with WordPressMobile Hybrid Development with WordPress
Mobile Hybrid Development with WordPress
 
WordPress Development Tools and Best Practices
WordPress Development Tools and Best PracticesWordPress Development Tools and Best Practices
WordPress Development Tools and Best Practices
 
Improve WordPress performance with caching and deferred execution of code
Improve WordPress performance with caching and deferred execution of codeImprove WordPress performance with caching and deferred execution of code
Improve WordPress performance with caching and deferred execution of code
 
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...
AD111 -- Harnessing the Power of Server-Side JavaScript and Other Advanced XP...
 
Naked and afraid Offline Mobile
Naked and afraid Offline MobileNaked and afraid Offline Mobile
Naked and afraid Offline Mobile
 
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.
Beyond Fluffy Bunny. How I leveraged WebObjects in my lean startup.
 
[English version] JavaFX and Web Integration
[English version] JavaFX and Web Integration[English version] JavaFX and Web Integration
[English version] JavaFX and Web Integration
 
Better Front-end Development in Atlassian Plugins
Better Front-end Development in Atlassian PluginsBetter Front-end Development in Atlassian Plugins
Better Front-end Development in Atlassian Plugins
 
High Performance JavaScript - Fronteers 2010
High Performance JavaScript - Fronteers 2010High Performance JavaScript - Fronteers 2010
High Performance JavaScript - Fronteers 2010
 
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012
User Macros: Making Your Own Improvements to Confluence - Atlassian Summit 2012
 
Ajax basics
Ajax basicsAjax basics
Ajax basics
 

Similar to JMP401: Masterclass: XPages Scalability

Camunda BPM 7.2: Performance and Scalability (English)
Camunda BPM 7.2: Performance and Scalability (English)Camunda BPM 7.2: Performance and Scalability (English)
Camunda BPM 7.2: Performance and Scalability (English)camunda services GmbH
 
Impact 2014 - IIB - selecting the right transformation option
Impact 2014 - IIB - selecting the right transformation optionImpact 2014 - IIB - selecting the right transformation option
Impact 2014 - IIB - selecting the right transformation optionAndrew Coleman
 
Lessons learned from the worlds largest XPage project
Lessons learned from the worlds largest XPage projectLessons learned from the worlds largest XPage project
Lessons learned from the worlds largest XPage projectMark Roden
 
Was l iberty for java batch and jsr352
Was l iberty for java batch and jsr352Was l iberty for java batch and jsr352
Was l iberty for java batch and jsr352sflynn073
 
We4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshell
We4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshellWe4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshell
We4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshellWe4IT Group
 
Virtualising Tier 1 Apps
Virtualising Tier 1 AppsVirtualising Tier 1 Apps
Virtualising Tier 1 AppsIwan Rahabok
 
Drools & jBPM Info Sheet
Drools & jBPM Info SheetDrools & jBPM Info Sheet
Drools & jBPM Info SheetMark Proctor
 
Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2
Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2
Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2Vladimir Bacvanski, PhD
 
What's New in IBM Java 8 SE?
What's New in IBM Java 8 SE?What's New in IBM Java 8 SE?
What's New in IBM Java 8 SE?Tim Ellison
 
Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...
Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...
Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...Alfresco Software
 
PERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACH
PERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACHPERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACH
PERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACHcscpconf
 
Performance comparison on java technologies a practical approach
Performance comparison on java technologies a practical approachPerformance comparison on java technologies a practical approach
Performance comparison on java technologies a practical approachcsandit
 
Jesy George_CV_LATEST
Jesy George_CV_LATESTJesy George_CV_LATEST
Jesy George_CV_LATESTJesy George
 
We4IT lcty 2013 - infra-man - whats new in ibm domino application development
We4IT lcty 2013 - infra-man - whats new in ibm domino application developmentWe4IT lcty 2013 - infra-man - whats new in ibm domino application development
We4IT lcty 2013 - infra-man - whats new in ibm domino application developmentWe4IT Group
 
Build & Deploy Scalable Cloud Applications in Record Time
Build & Deploy Scalable Cloud Applications in Record TimeBuild & Deploy Scalable Cloud Applications in Record Time
Build & Deploy Scalable Cloud Applications in Record TimeRightScale
 

Similar to JMP401: Masterclass: XPages Scalability (20)

Camunda BPM 7.2: Performance and Scalability (English)
Camunda BPM 7.2: Performance and Scalability (English)Camunda BPM 7.2: Performance and Scalability (English)
Camunda BPM 7.2: Performance and Scalability (English)
 
Impact 2014 - IIB - selecting the right transformation option
Impact 2014 - IIB - selecting the right transformation optionImpact 2014 - IIB - selecting the right transformation option
Impact 2014 - IIB - selecting the right transformation option
 
Lessons learned from the worlds largest XPage project
Lessons learned from the worlds largest XPage projectLessons learned from the worlds largest XPage project
Lessons learned from the worlds largest XPage project
 
Was l iberty for java batch and jsr352
Was l iberty for java batch and jsr352Was l iberty for java batch and jsr352
Was l iberty for java batch and jsr352
 
We4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshell
We4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshellWe4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshell
We4IT LCTY 2013 - x-pages-men - ibm domino xpages - performance in a nutshell
 
What's new in designer
What's new in designerWhat's new in designer
What's new in designer
 
Virtualising Tier 1 Apps
Virtualising Tier 1 AppsVirtualising Tier 1 Apps
Virtualising Tier 1 Apps
 
Technical Recruitment Overview & Tips
Technical Recruitment Overview & TipsTechnical Recruitment Overview & Tips
Technical Recruitment Overview & Tips
 
Drools & jBPM Info Sheet
Drools & jBPM Info SheetDrools & jBPM Info Sheet
Drools & jBPM Info Sheet
 
Bhanu Resume
Bhanu ResumeBhanu Resume
Bhanu Resume
 
Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2
Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2
Revolutionizing the Data Abstraction Layer with IBM Optim pureQuery and DB2
 
What's New in IBM Java 8 SE?
What's New in IBM Java 8 SE?What's New in IBM Java 8 SE?
What's New in IBM Java 8 SE?
 
Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...
Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...
Alfresco Day Barcelona 2016 - Developer Track - Herramientas para administrad...
 
KaranDeepSinghCV
KaranDeepSinghCVKaranDeepSinghCV
KaranDeepSinghCV
 
PERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACH
PERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACHPERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACH
PERFORMANCE COMPARISON ON JAVA TECHNOLOGIES - A PRACTICAL APPROACH
 
Performance comparison on java technologies a practical approach
Performance comparison on java technologies a practical approachPerformance comparison on java technologies a practical approach
Performance comparison on java technologies a practical approach
 
Jesy George_CV_LATEST
Jesy George_CV_LATESTJesy George_CV_LATEST
Jesy George_CV_LATEST
 
Resume
ResumeResume
Resume
 
We4IT lcty 2013 - infra-man - whats new in ibm domino application development
We4IT lcty 2013 - infra-man - whats new in ibm domino application developmentWe4IT lcty 2013 - infra-man - whats new in ibm domino application development
We4IT lcty 2013 - infra-man - whats new in ibm domino application development
 
Build & Deploy Scalable Cloud Applications in Record Time
Build & Deploy Scalable Cloud Applications in Record TimeBuild & Deploy Scalable Cloud Applications in Record Time
Build & Deploy Scalable Cloud Applications in Record Time
 

Recently uploaded

Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationSafe Software
 
WordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your BrandWordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your Brandgvaughan
 
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek SchlawackFwdays
 
Understanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitectureUnderstanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitecturePixlogix Infotech
 
Scanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsScanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsRizwan Syed
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfAlex Barbosa Coqueiro
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii SoldatenkoFwdays
 
SQL Database Design For Developers at php[tek] 2024
SQL Database Design For Developers at php[tek] 2024SQL Database Design For Developers at php[tek] 2024
SQL Database Design For Developers at php[tek] 2024Scott Keck-Warren
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024Lorenzo Miniero
 
"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr Bagan"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr BaganFwdays
 
Vertex AI Gemini Prompt Engineering Tips
Vertex AI Gemini Prompt Engineering TipsVertex AI Gemini Prompt Engineering Tips
Vertex AI Gemini Prompt Engineering TipsMiki Katsuragi
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Enterprise Knowledge
 
Commit 2024 - Secret Management made easy
Commit 2024 - Secret Management made easyCommit 2024 - Secret Management made easy
Commit 2024 - Secret Management made easyAlfredo García Lavilla
 
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmaticsKotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmaticscarlostorres15106
 
Pigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions
 
My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024The Digital Insurer
 
Unleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubUnleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubKalema Edgar
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Mattias Andersson
 

Recently uploaded (20)

Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry InnovationBeyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
Beyond Boundaries: Leveraging No-Code Solutions for Industry Innovation
 
WordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your BrandWordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your Brand
 
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
 
Understanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitectureUnderstanding the Laravel MVC Architecture
Understanding the Laravel MVC Architecture
 
Scanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsScanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL Certs
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdf
 
Hot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort Service
Hot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort ServiceHot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort Service
Hot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort Service
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko
 
SQL Database Design For Developers at php[tek] 2024
SQL Database Design For Developers at php[tek] 2024SQL Database Design For Developers at php[tek] 2024
SQL Database Design For Developers at php[tek] 2024
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
 
"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr Bagan"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr Bagan
 
Vertex AI Gemini Prompt Engineering Tips
Vertex AI Gemini Prompt Engineering TipsVertex AI Gemini Prompt Engineering Tips
Vertex AI Gemini Prompt Engineering Tips
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024
 
DMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special EditionDMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special Edition
 
Commit 2024 - Secret Management made easy
Commit 2024 - Secret Management made easyCommit 2024 - Secret Management made easy
Commit 2024 - Secret Management made easy
 
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmaticsKotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
 
Pigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food Manufacturing
 
My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024My INSURER PTE LTD - Insurtech Innovation Award 2024
My INSURER PTE LTD - Insurtech Innovation Award 2024
 
Unleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding ClubUnleash Your Potential - Namagunga Girls Coding Club
Unleash Your Potential - Namagunga Girls Coding Club
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?
 

JMP401: Masterclass: XPages Scalability

  • 1. JMP401: Masterclass: XPages Scalability Tony McGuckin, IBM Martin Donnelly, IBM © 2014 IBM Corporation
  • 2. 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.
  • 3. “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!”
  • 4. Good Morning! Welcome to JMP401… Tony McGuckin Senior Software Engineer Ireland Software Labs @tonymcguckin Martin Donnelly Software Architect Ireland Software Labs @tweeterdonnelly
  • 5. This Morning's Agenda… Understanding the “XPages Machine” Developing for Performance Architecting for Scalability Q&A
  • 6. 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
  • 8. 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
  • 9. 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
  • 10. Understanding the “XPages Machine” The Performance and Scalability Pyramid Consider the following...
  • 11. 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)
  • 12. 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)
  • 13. Understanding the “XPages Machine” The Performance and Scalability Pyramid Finding a balance between Performance and Scalability is the end goal!
  • 14. Understanding the “XPages Machine” The Performance and Scalability Pyramid Remember this though...
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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)
  • 22. 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...
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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)
  • 28. 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)
  • 29. 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)
  • 30. 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)
  • 31. 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)
  • 32. 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 ]
  • 33. 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 ]
  • 34. Understanding the “XPages Machine” The XPages Request Processing Lifecycle Most typically executed for HTTP GET & POST Requests
  • 35. Understanding the “XPages Machine” The XPages Request Processing Lifecycle GET = 1,6 Most typically executed for HTTP GET & POST Requests
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. 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
  • 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 41
  • 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 42
  • 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 ─ 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
  • 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 44
  • 45. 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
  • 46. 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!
  • 48. 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
  • 49. 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
  • 50. 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
  • 51. 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”
  • 52. 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”
  • 53. 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”
  • 54. 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(); .... }
  • 55. 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”); .... } }
  • 56. 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 … }
  • 57. 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 … }
  • 58. 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 … }
  • 59. 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 … }
  • 60. 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 … }
  • 61. 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 … }
  • 62. 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
  • 63. 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
  • 64. 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
  • 65. 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!
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. 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
  • 70. 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
  • 72. 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 ]
  • 73. 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 ]
  • 74. 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 ]
  • 75. 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 ]
  • 76. 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 ]
  • 77. 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 ]
  • 78. Architecting for Scalability The XPages State Management Layer Manages creation / removal of application, session, and component tree objects
  • 79. 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
  • 80. 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
  • 81. 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
  • 82. 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
  • 83. 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
  • 84. 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!
  • 85. 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!
  • 86. 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
  • 87. 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
  • 88. 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
  • 89. 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
  • 90. 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
  • 91. 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
  • 92. 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
  • 93. 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
  • 94. 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
  • 95. 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
  • 96. 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
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. 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
  • 101. 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
  • 102. 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)
  • 103. 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
  • 104. 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
  • 105. 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
  • 106. 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
  • 107. 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
  • 108. 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
  • 109. 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
  • 110. 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
  • 111. 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
  • 112. 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
  • 113. 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?
  • 114. 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
  • 115. 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
  • 116. 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
  • 117. 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
  • 118. 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
  • 119. 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
  • 120. 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
  • 121. 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
  • 122. 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!
  • 123. 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
  • 124. 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)
  • 125. 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)
  • 126. 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
  • 127. 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 Low vertical cost precondition  Maximum Scalability potential will not be possible if there are underlying vertical cost issues still to be rectified
  • 128. 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 Serialization  More detail coming up...
  • 129. 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 Serialization  More detail coming up...
  • 130. 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 Minimum Hold  Application and Session timeout durations default to 30 minutes. Try to maintain these values or lower. Increasing these values increases horizontal cost!
  • 131. 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 time-outs – 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 Gzip Compression  Only use this option after careful analysis of the Host System behaviour under upper limit work load as it CPU intensive
  • 132. 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 time-outs – 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 Mastering XPages, 2nd Edition  Chapter 20 focuses on the mechanics of the X-SML relative to enabling an application to scale well  In-depth explanation and practical study of RAM and Disk Persistence options  Explains memory analysis using the Eclipse Memory Analyser and XPages Toolbox Session Dumps with practical study
  • 133. Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – Custom Java / Managed Beans must implement the java.io.Serializable interface otherwise a java.io.NotSerializableException will be thrown when trying to use Disk Persistence! – Other Java pointers... • Use the transient modifier for unserializable or internally cached/calculated members → to reduce serialized footprint / avoid exceptions / reduce processing • Minimise duplicate Strings → consider shared constants / instances • Avoid initialising large empty HashMaps → consider lazyloading where possible
  • 134. Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – Custom Java / Managed Beans must implement the java.io.Serializable interface otherwise a java.io.NotSerializableException will be thrown when trying to use Disk Persistence! – Other Java pointers... • Use the transient modifier for unserializable or internally cached/calculated members → to reduce serialized footprint / avoid exceptions / reduce processing • Minimise duplicate Strings → consider shared constants / instances • Avoid initialising large empty HashMaps → consider lazyloading where possible
  • 135. Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – Custom Java / Managed Beans must implement the java.io.Serializable interface otherwise a java.io.NotSerializableException will be thrown when trying to use Disk Persistence! – Other Java pointers... • Use the transient modifier for unserializable or internally cached/calculated members → to reduce serialized footprint / avoid exceptions / reduce processing • Minimise duplicate Strings → consider shared constants / instances • Avoid initialising large empty HashMaps → consider lazyloading where possible
  • 136. Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – ServerSide JavaScript (SSJS) Objects/Functions cannot be serialized into the viewScope variable when using Disk Persistence otherwise a java.io.NotSerializableException will be thrown! – If your business logic involves buffering SSJS Objects/Functions into the viewScope variable and scalability is important → consider porting into serializable Managed Beans to gain the benefits of Disk Persistence
  • 137. Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – ServerSide JavaScript (SSJS) Objects/Functions cannot be serialized into the viewScope variable when using Disk Persistence otherwise a java.io.NotSerializableException will be thrown! – If your business logic involves buffering SSJS Objects/Functions into the viewScope variable and scalability is important → consider porting into serializable Managed Beans to gain the benefits of Disk Persistence
  • 138. Architecting for Scalability Moving to the “X” Level! → Serialization  Serialization is the process of writing/reading XPage component tree state to/from RAM and/or Disk Persistence – ServerSide JavaScript (SSJS) Objects/Functions cannot be serialized into the viewScope variable when using Disk Persistence otherwise a java.io.NotSerializableException will be thrown! – If your business logic involves buffering SSJS Objects/Functions into the viewScope variable and scalability is important → consider porting into serializable Managed Beans to gain the benefits of Disk Persistence
  • 139. Architecting for Scalability  You should now understand the demands placed upon a Host System by the “XPages Machine”  You also have seen how to gain insight into the vertical and horizontal costs by using the XPages Toolbox and Eclipse Memory Analyzer
  • 140. Architecting for Scalability  You should now understand the demands placed upon a Host System by the “XPages Machine”  You also have seen how to gain insight into the vertical and horizontal costs by using the XPages Toolbox and Eclipse Memory Analyzer
  • 141. Architecting for Scalability  You should now understand the demands placed upon a Host System by the “XPages Machine”  You also have seen how to gain insight into the vertical and horizontal costs by using the XPages Toolbox and Eclipse Memory Analyzer So how can you determine if a Host System has the potential to cope with the scalability demands of a given application and request load?
  • 142. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
  • 143. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
  • 144. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
  • 145. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  Many different equations can be derived to determine potential capability and capacity of a given Host System relative to the “responsiveness and expected load” requirements  Many different inputs/factors exist beyond vertical/horizontal costs within the Host System – ie: Other factor areas: Browser / Network / Distributed Architecture / ...  XPages Vertical/Horizontal Cost Analysis is a general guideline to help approximate Host System scalability potential dependant upon careful CPU and Memory profiling and analysis  Could potentially form part of a more specific equation/approach relative to a given Host System, its Application working set and its specific performance/scalability requirements
  • 146. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  You should also consider using a dedicated Performance and Scalability automation testing tool to mimic “real” concurrent user work loads / network conditions / etc – IBM Rational Performance Tester http://www-03.ibm.com/software/products/en/performance/ – The Grinder http://grinder.sourceforge.net/  Note: The automation tool should reside on a separate “test” machine – not on the actual source application server otherwise profiling and analysis results will be distorted!
  • 147. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis  You should also consider using a dedicated Performance and Scalability automation testing tool to mimic “real” concurrent user work loads / network conditions / etc – IBM Rational Performance Tester http://www-03.ibm.com/software/products/en/performance/ – The Grinder http://grinder.sourceforge.net/  Note: The automation tool should reside on a separate “test” machine – not on the actual source application server otherwise profiling and analysis results will be distorted!
  • 148. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example Equation V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H =: V . R P =: C / H If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
  • 149. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example for Memory (Underload) V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H(300Mb) =: V(1mb) . R(300 users) P(3.41) =: C(1Gb) / H(300Mb) If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
  • 150. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example for Memory (Maximum) V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H(1000Mb) =: V(1mb) . R(1000 users) P(1) =: C(1000Mb) / H(1000Mb) If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
  • 151. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis – Example for Memory (Overload) V → Vertical Cost C → Host System Capacity R → Request Load P → Potential Factor H → Horizontal Cost S → Scalability Potential H(4000Mb) =: V(8Mb) . R(500 users) P(0.77) =: C(3Gb) / H(4000Mb) If (P < 1.0) then S = Overload: Potential for only (P)% of (H) If (P = 1.0) then S = Maximum: Potential for 100% of (H) If (P > 1.0) then S = Underload: Potential for (P) times (H)
  • 152. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis Test Case: XPages Insights Into Big Data
  • 153. Architecting for Scalability XPages Vertical/Horizontal Cost Analysis Host System  WIN7 Professional 64bit  24Gb RAM  Intel CORE i7 vPro 8 x CPU  448Gb HDD  Domino 9.0.1 64bit – JVM Heap: 10Gb
  • 155. 155
  • 156.  Access Connect Online to complete your session surveys using any: – Web or mobile browser – Connect Online kiosk onsite
  • 157. Engage Online  SocialBiz User Group socialbizug.org – Join the epicenter of Notes and Collaboration user groups  Follow us on Twitter – @IBMConnect and @IBMSocialBiz  LinkedIn http://bit.ly/SBComm – Participate in the IBM Social Business group on LinkedIn:  Facebook https://www.facebook.com/IBMSocialBiz – Like IBM Social Business on Facebook  Social Business Insights blog ibm.com/blogs/socialbusiness – Read and engage with our bloggers
  • 158. Acknowledgements and Disclaimers Availability. References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. © Copyright IBM Corporation 2014. All rights reserved.  U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.  IBM, the IBM logo, ibm.com, Notes, Domino, and XPages are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml Other company, product, or service names may be trademarks or service marks of others.