JMP401: Masterclass: XPages Scalability

© 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”The Performance and Scalability Pyramid

Performance and Scalability are two separate entities

Each can conflict with the interests and goals of the other


Performance and Scalability are two separate entities

Each can conflict with the interests and goals of the other


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.


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.


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!



Remember this though...


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


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




















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






CPU Memory

(RAM & Disk)









CPU Memory

(RAM & Disk)









CPU Memory

(RAM & Disk)









CPU Memory

(RAM & Disk)




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



nlnotes.exe



XSP Component Trees


XLIB

*.nsf

X-RPL Process


XPages Request Processing Lifecycle

Understanding the “XPages Machine”The XPages Request Processing Lifecycle

Most typically executed for

HTTP GET & POST Requests




GET = 1,6




GET = 1,6

POST = 1,2,3,4,5,6




GET = 1,6

POST = 1,2,3,4,5,6

2 x System Level Phases

[ 1,6 ] Executed for most

HTTP GET & POST

Requests




GET = 1,6

POST = 1,2,3,4,5,6



HTTP GET & POST

Requests

4 x Application Level

Phases [ 2,3,4,5 ]

Executed for HTTP POST

Requests




GET = 1,6

POST = 1,2,3,4,5,6



HTTP GET & POST

Requests


Phases [ 2,3,4,5 ]


Requests

4 x Event Pseudo-Phases [

2,3,4,5 ] Executed for

HTTP POST Requests




GET = 1,6

POST = 1,2,3,4,5,6



HTTP GET & POST

Requests


Phases [ 2,3,4,5 ]


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


42






43






44


Domino server console or Notes client OSGi console must be

available to analyze details

C:\n1\notes.exe "=C:\n1\notes.ini" -RPARAMS -console


45


Domino server console or Notes client OSGi console must be

available to analyze details

C:\n1\notes.exe "=C:\n1\notes.ini" -RPARAMS -console



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









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();....

}


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”);....

}}


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
































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












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!


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







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







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







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


nhttp.exe

OSGi Framework

XPagesRuntime



nlnotes.exe



XSP Component Trees


XLIB

*.nsf

X-RPL Process

Architecting for ScalabilityLooking at an XPages request again...

nhttp.exe

OSGi Framework

XPagesRuntime



nlnotes.exe



XSP Component Trees


XLIB

*.nsf

X-RPL Process



nhttp.exe

OSGi Framework

XPagesRuntime



nlnotes.exe



XSP Component Trees


XLIB

*.nsf

X-RPL Process


Hardware

Product

Code

Design


nhttp.exe

OSGi Framework

XPagesRuntime



nlnotes.exe



XSP Component Trees


XLIB

*.nsf

X-RPL Process


nhttp.exe

OSGi Framework

XPagesRuntime



nlnotes.exe



XSP Component Trees


XLIB

*.nsf

X-RPL Process


XPages State Management Layer

nhttp.exe

OSGi Framework

XPagesRuntime



nlnotes.exe



XSP Component Trees


XLIB

*.nsf

X-RPL Process


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


Manages creation / removal of application, session, and component tree objects

Serializes / Deserializes XPage State as end user interacts with application


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






Manages memory usage on a LRU algorithm / maximum views configuration





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





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!


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














HTTPJVMMaxHeapSize=256MHTTPJVMMaxHeapSizeSet=1





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













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
















In fact, so large that JVM Heap size can be set > than available RAM because address spaces are still available


















In fact, so large that JVM Heap size can be set > than available RAM because address spaces are still available



“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









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


“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


“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


“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


“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

“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

“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


“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


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


But what about vertical and horizontal memory costs?




Analyze using JVM Heap Dumps




Analyze using JVM Heap DumpsAnalyze using JVM System Dumps




Analyze using JVM Heap DumpsAnalyze using JVM System DumpsAnalyze using XML Session 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

http://www.eclipse.org/mat/




















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


java.util.HashMap





(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


java.util.HashMap





(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!






Low vertical cost precondition

Maximum Scalability potential will not be possible if there are underlying vertical cost issues still to be rectified








Serialization

More detail coming up...







Serialization

More detail coming up...







Minimum Hold

Application and Session timeout durations default to 30 minutes. Try to maintain these values or lower. Increasing these values increases horizontal cost!



– Make Java/Beans implement java.io.Serializable– Avoid buffering SSJS Objects/Functions into viewScope– Apply Minimum Hold with low Application/Session time-outs




Gzip Compression

Only use this option after careful analysis of the Host System behaviour under upper limit work load as it CPU intensive



– Make Java/Beans implement java.io.Serializable– Avoid buffering SSJS Objects/Functions into viewScope– Apply Minimum Hold with low Application/Session time-outs



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


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
















– 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










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

















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!




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


– The Grinder


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)




V → Vertical Cost

R → Request Load





H(1000Mb) =: V(1mb) . R(1000 users)P(1) =: C(1000Mb) / H(1000Mb)

Architecting for ScalabilityXPages Vertical/Horizontal Cost Analysis – Example for Memory (Maximum)




V → Vertical Cost

R → Request Load





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)




V → Vertical Cost

R → Request Load






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


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

https://reg.socialbizug.org/wispubs/socbizwidgets.nsf/homepage.xsp

https://twitter.com/IBMConnect




https://twitter.com/IBMSocialBiz

https://twitter.com/IBMSocialBiz

http://bit.ly/SBComm

http://bit.ly/SBComm

https://www.facebook.com/IBMSocialBiz

https://www.facebook.com/IBMSocialBiz

http://www.ibm.com/blogs/socialbusiness

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.

http://www.ibm.com/legal/copytrade.shtml

Technology

JMP401: Masterclass: XPages Scalability