© 2014 IBM Corporation JMP401: Masterclass: XPages Scalability Tony McGuckin, IBM Martin Donnelly, IBM
Nov 29, 2014
© 2014 IBM Corporation
JMP401: Masterclass: XPages ScalabilityTony McGuckin, IBMMartin Donnelly, IBM
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!”
Tony McGuckinSenior Software Engineer
Ireland Software Labs@tonymcguckin
Martin DonnellySoftware Architect
Ireland Software Labs@tweeterdonnelly
Good Morning!Welcome to JMP401…
This Morning's Agenda…
Understanding the “XPages Machine”
Developing for Performance
Architecting for Scalability
Q&A
6
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!
Caution: May Contain Nuts...
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...
“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.
Understanding the “XPages Machine”The Performance and Scalability Pyramid
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)
“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.
Understanding the “XPages Machine”The Performance and Scalability Pyramid
A case of being able to scale up and/or out (vertical / horizontal scale) but performance needs corrective action (→ Design/Code Tuning)
Finding a balance between Performance and Scalability is the end goal!
Understanding the “XPages Machine”The Performance and Scalability Pyramid
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
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
Degree of Impact is largest at the bottom of the pyramid. Positive changes to design and code will always yield most
Understanding the “XPages Machine”The Performance and Scalability Pyramid
Hardware
Product
Code
Design
Layers of Tuning
Degree of Impact
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 and the JavaServer Faces® Framework
─ 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”XPages Specific Extensions / Capabilities over JSF RI
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”
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
The Host System has two critical parts that determine how an application behaves:
CPU Memory
(RAM & Disk)
A Distributed System Architecture presents its own challenges:
Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation
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
The Host System has two critical parts that determine how an application behaves:
CPU Memory
(RAM & Disk)
A Distributed System Architecture presents its own challenges:
Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation
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
The Host System has two critical parts that determine how an application behaves:
CPU Memory
(RAM & Disk)
A Distributed System Architecture presents its own challenges:
Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation
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
The Host System has two critical parts that determine how an application behaves:
CPU Memory
(RAM & Disk)
A Distributed System Architecture presents its own challenges:
Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation
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
The Host System has two critical parts that determine how an application behaves:
CPU Memory
(RAM & Disk)
A Distributed System Architecture presents its own challenges:
Data Replication & Indexing Conflict Resolution On/Offline Execution (XPiNC) Node Availability / Failover Design Propagation
Understanding the “XPages Machine”Factors that effect Performance and Scalability
This morning we are focusing on the Host System area:
#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 → Secondary objective is minimizing Memory usage
#2 Understanding the XPages State Management Layer is equally as important to write highly efficient code, but also for configuring / tuning an application and the XPages Runtime to achieve a low horizontal cost → Primary objective is minimizing Memory usage → Secondary objective is minimizing CPU usage
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Understanding the “XPages Machine”A deeper look at an XPages Request
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Understanding the “XPages Machine”A deeper look at an XPages Request
XPages Request Processing Lifecycle
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
Most typically executed for
HTTP GET & POST Requests
GET = 1,6
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
Most typically executed for
HTTP GET & POST Requests
GET = 1,6
POST = 1,2,3,4,5,6
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
Most typically executed for
HTTP GET & POST Requests
GET = 1,6
POST = 1,2,3,4,5,6
2 x System Level Phases
[ 1,6 ] Executed for most
HTTP GET & POST
Requests
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
Most typically executed for
HTTP GET & POST Requests
GET = 1,6
POST = 1,2,3,4,5,6
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
Most typically executed for
HTTP GET & POST Requests
GET = 1,6
POST = 1,2,3,4,5,6
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
Most typically executed for
HTTP GET & POST Requests
GET = 1,6
POST = 1,2,3,4,5,6
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
Phase execution can be
optimized per Request to
lower Performance cost!
41
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.javafaces-config.xml / index.xsp
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
42
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.javafaces-config.xml / index.xsp
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
43
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.javafaces-config.xml / index.xsp
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
44
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:\n1\notes.exe "=C:\n1\notes.ini" -RPARAMS -console
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
45
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:\n1\notes.exe "=C:\n1\notes.ini" -RPARAMS -console
Understanding the “XPages Machine”The XPages Request Processing Lifecycle
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
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 PerformanceThe 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 PerformanceThe 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 PerformanceThe 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceUsing 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 PerformanceThe XPages Toolbox
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 PerformanceA 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 PerformanceA Lean, Mean “XPages Machine”!
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
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 PerformanceA Lean, Mean “XPages Machine”!
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
It will be invoked up to four times during a POST back request so must be used sparingly or avoided
loaded is an absolute property and only invoked during the initial Page Load event therefore requires a context.reloadPage() or Complete Refresh to reinvoke
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 PerformanceA Lean, Mean “XPages Machine”!
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!
Partial Refresh requests can be issued against an instance within a component tree using a range of SSJS / CSJS methods
It provides the ability to update the browser URL for bookmarking and back-button support of dynamically retrieved AJAX content
It supports SEO Robot indexing
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 PerformanceA Lean, Mean “XPages Machine”!
Mastering XPages, 2nd Edition
Chapter 20 focuses on the low-level 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
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Architecting for ScalabilityLooking at an XPages request again...
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Architecting for ScalabilityLooking at an XPages request again...
XPages Request Processing Lifecycle
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Architecting for ScalabilityLooking at an XPages request again...
Hardware
Product
Code
Design
XPages Request Processing Lifecycle
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Architecting for ScalabilityLooking at an XPages request again...
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Architecting for ScalabilityLooking at an XPages request again...
XPages State Management Layer
nhttp.exe
OSGi Framework
XPagesRuntime
XPagesExtensions[OSGi Bundles]
JavaServer FacesFramework
nlnotes.exe
Backend, C/C++ Services (NSF,NIF,etc), Database Layers
NSF Applications[ Component Modules ]
XSP Component Trees
State Management Layer
XLIB
*.nsf
X-RPL Process
Architecting for ScalabilityLooking at an XPages request again...
Hardware
Product
Code
Design
XPages State Management Layer
Architecting for ScalabilityThe XPages State Management Layer
Manages creation / removal of application, session, and component tree objects
Architecting for ScalabilityThe XPages State Management Layer
Manages creation / removal of application, session, and component tree objects
Serializes / Deserializes XPage State as end user interacts with application
Architecting for ScalabilityThe XPages State Management Layer
Manages creation / removal of application, session, and component tree objects Can be configured
per application to use either RAM and/or Disk allocated memory space for component trees
Serializes / Deserializes XPage State as end user interacts with application
Architecting for ScalabilityThe XPages State Management Layer
Manages creation / removal of application, session, and component tree objects Can be configured
per application to use either RAM and/or Disk allocated memory space for component trees
Serializes / Deserializes XPage State as end user interacts with application
Manages memory usage on a LRU algorithm / maximum views configuration
Architecting for ScalabilityThe XPages State Management Layer
Manages creation / removal of application, session, and component tree objects Can be configured
per application to use either RAM and/or Disk allocated memory space for component trees
Serializes / Deserializes XPage State as end user interacts with application
Can be configured per application to compress the serialized state of a component tree for disk storage
Manages memory usage on a LRU algorithm / maximum views configuration
Architecting for ScalabilityThe XPages State Management Layer
Manages creation / removal of application, session, and component tree objects Can be configured
per application to use either RAM and/or Disk allocated memory space for component trees
Serializes / Deserializes XPage State as end user interacts with application
Can be configured per application to compress the serialized state of a component tree for disk storage
Can perform delta level updates during serialization Manages memory usage on
a LRU algorithm / maximum views configuration
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 ScalabilityThe 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 ScalabilityThe 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 meta-data, 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 ScalabilityThe 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 meta-data, 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 ScalabilityThe 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 meta-data, 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 ScalabilityThe 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 meta-data, 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 ScalabilityThe XPages State Management Layer – JVM Memory Structure
HTTPJVMMaxHeapSize=256MHTTPJVMMaxHeapSizeSet=1
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 meta-data, 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 ScalabilityThe XPages State Management Layer – JVM Memory Structure
HTTPJVMMaxHeapSize=256MHTTPJVMMaxHeapSizeSet=1RAM
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 meta-data, 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 ScalabilityThe XPages State Management Layer – JVM Memory Structure
HTTPJVMMaxHeapSize=256MHTTPJVMMaxHeapSizeSet=1RAM
JVM Heap → 32 Bit Operating System
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)
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
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 meta-data, 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 ScalabilityThe XPages State Management Layer – JVM Memory Structure
HTTPJVMMaxHeapSize=256MHTTPJVMMaxHeapSizeSet=1RAM
JVM Heap → 32 Bit Operating System
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)
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
JVM Heap → 64 Bit Operating System
Limited to maximum 64bit address which is infinitely larger than any available RAM
Minus OS allocated RAM space and OS limits– ie: Win7 Enterprise → Max: 192Gb
Therefore, maximum 64bit JVM Heap size can stretch far beyond 32bit 1.5Gb boundary
In fact, so large that JVM Heap size can be set > than RAM as address spaces are still available
– However, the system will start “paging” or “thrashing” which makes things very slow!
So maximum 64bit JVM Heap size should ideally be set somewhere up to maximum available RAM size with consideration of all related factors
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 meta-data, 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 ScalabilityThe XPages State Management Layer – JVM Memory Structure
HTTPJVMMaxHeapSize=256MHTTPJVMMaxHeapSizeSet=1RAM
JVM Heap → 32 Bit Operating System
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)
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
JVM Heap → 64 Bit Operating System
Limited to maximum 64bit address which is infinitely larger than any available RAM
Minus OS allocated RAM space
Therefore, maximum 64bit JVM Heap size can stretch far beyond 32bit 1.5Gb boundary
In fact, so large that JVM Heap size can be set > than available RAM because address spaces are still available
– However, the system will start “paging” or “thrashing” which makes things very slow!
So maximum 64bit JVM Heap size should ideally be set somewhere up to maximum available RAM size with consideration of all related factors
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 meta-data, 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 ScalabilityThe XPages State Management Layer – JVM Memory Structure
HTTPJVMMaxHeapSize=256MHTTPJVMMaxHeapSizeSet=1RAM
JVM Heap → 32 Bit Operating System
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)
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
JVM Heap → 64 Bit Operating System
Limited to maximum 64bit address which is infinitely larger than any available RAM
Minus OS allocated RAM space
Therefore, maximum 64bit JVM Heap size can stretch far beyond 32bit 1.5Gb boundary
In fact, so large that JVM Heap size can be set > than available RAM because address spaces are still available
– However, the system will start “paging” or “thrashing” which makes things very slow!
So maximum 64bit JVM Heap size should ideally be set somewhere up to maximum available RAM size with consideration of all related factors
“What is the best JVM Heap Size?”
No “silver bullet” can be commonly applied!
Should be calculated based upon stakeholder expectations / requirements of an application / host system
Requires careful memory profiling and analysis into horizontal cost for different application workflow use cases / request loads
Make the effort to correct vertical and horizontal cost issues as you develop / test to ensure applications are as efficient as possible!
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 ScalabilityThe 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 ScalabilityThe 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 ScalabilityThe XPages State Management Layer – Disk Persistence
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 ScalabilityThe 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 ScalabilityThe 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 ScalabilityThe 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 ScalabilityThe XPages State Management Layer – Persistence Options
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 ScalabilityThe 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 ScalabilityThe XPages State Management Layer – xsp.properties
“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 low-range scalability is only possible
Architecting for ScalabilityThe 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 low-range scalability is only possible
Architecting for ScalabilityThe 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 ScalabilityThe 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 ScalabilityThe XPages State Management Layer – Persistence Options
“Keep only the current page in memory”
Architecting for ScalabilityThe XPages State Management Layer – Persistence Options
–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
“Keep only the current page in memory”
Architecting for ScalabilityThe XPages State Management Layer – Persistence Options
–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
“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 ScalabilityThe 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 ScalabilityThe XPages State Management Layer – Persistence Options
CPU, Wall Time, and Backend profiling gives insight into the vertical processing costs for any given XPage request
Architecting for ScalabilitySurface 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 ScalabilitySurface 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 ScalabilitySurface 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 DumpsAnalyze using JVM System Dumps
Architecting for ScalabilitySurface 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 DumpsAnalyze using JVM System DumpsAnalyze using XML Session Dumps
Architecting for ScalabilitySurface Zero - Analysing Memory Usage
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 ScalabilityAnalysing 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 ScalabilityAnalysing 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 ScalabilityAnalysing Memory Usage – JVM Heap & System 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 ScalabilityAnalysing 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 ScalabilityAnalysing Memory Usage – 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 ScalabilityHeap/System/XML Session Dumps
javax.faces.component.UIViewRoot$ViewMap
com.ibm.xsp.component.UIViewRootEx2
com.ibm.xsp.application.BasicStateManagerImpl$ViewHolder$PageEntry
com.ibm.xsp.application.BasicStateManagerImpl$ViewHolder
java.util.Hashtable
com.ibm.designer.runtime.domino.adapter.servlet.LCDAdapterHttpSession
java.util.HashMap
com.ibm.domino.xsp.module.nsf.NSFComponentModule
Architecting for ScalabilityHeap/System Dumps – OQL / Navigating XSP Objects Entry Point...
(1) x NSFComponentModule → (M) x LCDAdapterHttpSession
(1) x Application → (1) x NSFComponentModule
(1) x LCDAdapterHttpSession → (1) x $ViewHolder
(1) x $ViewHolder → (M[4]) x $PageEntry
(1) x $PageEntry → (1) x UIViewRootEx2
(1) x UIViewRootEx2 → viewScope, etc
Object containing RAM Persistence component trees (4)
“Keep pages in memory”
javax.faces.component.UIViewRoot$ViewMap
com.ibm.xsp.component.UIViewRootEx2
com.ibm.xsp.application.FileStateManager$ViewState[16]
com.ibm.xsp.application.FileStateManager$SessionState
java.util.Hashtable
com.ibm.designer.runtime.domino.adapter.servlet.LCDAdapterHttpSession
java.util.HashMap
com.ibm.domino.xsp.module.nsf.NSFComponentModule
Architecting for ScalabilityHeap/System Dumps – OQL / Navigating XSP Objects Entry Point...
(1) x NSFComponentModule → (M) x LCDAdapterHttpSession
(1) x Application → (1) x NSFComponentModule
(1) x LCDAdapterHttpSession → (1) x $SessionState
(1) x $SessionState → (M[16]) x $ViewState
(1) x $PageEntry → (1) x UIViewRootEx2
(1) x UIViewRootEx2 → viewScope, etc
Reference object to Disk Persistence component trees (16)
“Keep current page in memory”
Object containing current RAM Persistence component tree (1)
java.io.File
com.ibm.xsp.application.FileStateManager$ViewState
com.ibm.xsp.application.FileStateManager$ViewState[16]
com.ibm.xsp.application.FileStateManager$SessionState
java.util.Hashtable
com.ibm.designer.runtime.domino.adapter.servlet.LCDAdapterHttpSession
java.util.HashMap
com.ibm.domino.xsp.module.nsf.NSFComponentModule
Architecting for ScalabilityHeap/System Dumps – OQL / Navigating XSP Objects Entry Point...
(1) x NSFComponentModule → (M) x LCDAdapterHttpSession
(1) x Application → (1) x NSFComponentModule
(1) x LCDAdapterHttpSession → (1) x $SessionState
(1) x $SessionState → (M[16]) x $ViewState
(1) x $ViewState → (1) x File
Reference object to Disk Persistence component trees (16)
“Keep pages on disk”
Component tree state serialized in disk *.ser file
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 ScalabilityMoving 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 ScalabilityMoving 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 ScalabilityMoving to the “X” Level!
Serialization
More detail coming up...
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 ScalabilityMoving to the “X” Level!
Serialization
More detail coming up...
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 ScalabilityMoving to the “X” Level!
Minimum Hold
Application and Session timeout durations default to 30 minutes. Try to maintain these values or lower. Increasing these values increases horizontal cost!
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
Architecting for ScalabilityMoving to the “X” Level!
Gzip Compression
Only use this option after careful analysis of the Host System behaviour under upper limit work load as it CPU intensive
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 ScalabilityMoving to the “X” Level!
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 ScalabilityMoving 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 ScalabilityMoving 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 ScalabilityMoving 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 ScalabilityMoving 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 ScalabilityMoving 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 ScalabilityMoving to the “X” Level! → Serialization
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
Architecting for Scalability
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 ScalabilityXPages 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 ScalabilityXPages 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 ScalabilityXPages 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 ScalabilityXPages 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 ScalabilityXPages 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 ScalabilityXPages 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!
H =: V . RP =: C / H
Architecting for ScalabilityXPages Vertical/Horizontal Cost Analysis – Example Equation
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)
V → Vertical Cost
R → Request Load
H → Horizontal Cost
C → Host System Capacity
P → Potential Factor
S → Scalability Potential
H(300Mb) =: V(1mb) . R(300 users)P(3.41) =: C(1Gb) / H(300Mb)
Architecting for ScalabilityXPages Vertical/Horizontal Cost Analysis – Example for Memory (Underload)
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)
V → Vertical Cost
R → Request Load
H → Horizontal Cost
C → Host System Capacity
P → Potential Factor
S → Scalability Potential
H(1000Mb) =: V(1mb) . R(1000 users)P(1) =: C(1000Mb) / H(1000Mb)
Architecting for ScalabilityXPages Vertical/Horizontal Cost Analysis – Example for Memory (Maximum)
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)
V → Vertical Cost
R → Request Load
H → Horizontal Cost
C → Host System Capacity
P → Potential Factor
S → Scalability Potential
H(4000Mb) =: V(8Mb) . R(500 users)P(0.77) =: C(3Gb) / H(4000Mb)
Architecting for ScalabilityXPages Vertical/Horizontal Cost Analysis – Example for Memory (Overload)
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)
V → Vertical Cost
R → Request Load
H → Horizontal Cost
C → Host System Capacity
P → Potential Factor
S → Scalability Potential
Architecting for ScalabilityXPages Vertical/Horizontal Cost Analysis
Test Case:XPages Insights Into Big Data
Host System WIN7 Professional 64bit 24Gb RAM Intel CORE i7 vPro 8 x CPU 448Gb HDD Domino 9.0.1 64bit
– JVM Heap: 10Gb
Architecting for ScalabilityXPages Vertical/Horizontal Cost Analysis
154
Q&A
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
© 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.
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.