Ad109 - XPages Performance and Scalability

transcript

AD109: XPages Performance & ScalabilityTony McGuckin | IBM Software Engineer, XPages RuntimeMark Gargan | IBM Software Engineer, Quickr Domino

AbstractUnderstanding the XPages architecture is key to building

performant scalable enterprise-ready IBM Lotus® Domino® web applications.

We'll show how to go under the hood to discover functional features that help your application perform and scale well.

You'll learn about design patterns and techniques that ensure your applications are optimally tuned for your business requirements, and we'll show how to integrate existing business logic -- without increasing performance cost.

Agenda● Who are we?

● What's this session about?

● Understanding the problems

● XPages – Optimizing application execution within the server

● XPages – Optimizing application design and browser output

● Q&A

Who are we?● Tony McGuckin

▬ IBM Software Engineer, Dublin Software Lab, Ireland▬ XPages Server Runtime

● Product & Template development● Customer Enablement & Proof-of-Concept development● Co-creator of global XPages@... Workshops

▬ Lotus OneUI Adoption Workgroup▬ Speaker @

▬ Lotusphere 09 – Resonance▬ IBM Premium Support Seminar▬ IBM EMEA ISSL Technical Seminar▬ Lotus Technical Conference▬ ...

Who are we?● Mark Gargan

▬ IBM Software Engineer, Dublin Software Lab, Ireland

● Understanding the problem

● Q&A

What's this session about?● XPages in 8.5.1 comes with several important performance and

scalability features● Some are implicitly applied, whilst others require some slight

design changes to your application● These features are designed to optimize two key drivers that

effect application performance and scalability:▬ CPU (or Microprocessor) Usage▬ Memory Consumption

● This session aims to explore the underlying problems that can cause performance and scalability issues, and teach you how to overcome them so your XPages applications succeed!

● Q&A

Understanding the problems● The underlying server hardware has two critical parts that

ultimately determine how an application behaves under stress and load

▬ CPU (Central Processing Unit) or Microprocessor▬ Memory (both Virtual and Physical)

Understanding the problems● CPU (Central Processing Unit) or Microprocessor

▬ Is the “brains” of a computer where all the binary calculations take place▬ Each has an approved “clock” speed / maximum processing threshold

▬ Overuse will result in:● Degraded performance by way of slower response times

● Memory▬ Is a storage mechanism for data and/or CPU instructions▬ Two types exist ~ Virtual and ~ Physical▬ Upper limits on the amount of usable memory exist for any given machine

▬ Overuse will result in:● Degraded scalability by way of resource blocking and contention

● Symptoms of both function being over-utilized are:▬ Very poorly performing / non-responsive applications▬ A hanging server

Understanding the problems● In between the server hardware and the requesting client

(browser) machine sits a network. This element experiences its own stress and load issues

▬ Bandwidth▬ Latency▬ Contention

Understanding the problems● The requesting client (browser) also has its own work to do in

order to process any given request or response. Factors effecting this are

▬ Caching policy of resources▬ Size of request or response▬ Number of requests and responses▬ Parsing the JavaScript▬ Calculating the layout▬ Rendering the age

Understanding the problems● XPages is built upon the JavaServer Faces™ framework● Important to understand the principles of this framework

▬ Stateful Web Application Architecture▬ Therefore providing server-side state mechanisms

▬ Component-based Architecture▬ Every tag on a page relates to a server-side object

representation● Responsible for saving/restoring state● Validating values against component logic● Rendering the visual markup representation

▬ A Six Phase lifecycle is utilized by this framework and extended by XPages

* http://www.ibm.com/developerworks/java/library/j-jsf2/

Understanding the problems● The six phase server-side XPages lifecycle finishes by rendering

the response to the requesting browser● Several processing stages are then executed on the response

content before it is viewable or completed within the requesting browser

● How you design and implement your XPages code has an impact on the efficiency of these processing stages

▬ Factors to consider include:▬ Number of components on the page▬ Complexity of script (both server- and client-side)▬ Mass weight of resources (images, CSS, etc)▬ Use of Ajax requests▬ And so on...

Tools – Profiling Your Application

● Firebug– Firefox extension

● PageSpeed– Firefox/Firebug extension

● YSlow!– Firefox/Firebug extension

● Speed Tracer– Google Chrome Extension

Tools - Firebug

Tools – Page Speed

Tools – YSlow!

Tools – Speed Tracer

● Q&A

Performance – CPU Optimization● Avoid all the other lifecycle phases whenever possible

– This means use GET requests when possible● Instead of using an "Open Page" simple action for a link, use the

link type (URL or Open Page) and Parameters properties– This has several side effects:

● Phases 1-5 of are not processed, as this is just a GET● It avoids an HTTP Client Redirect request

– Because the browser needs to be aware of the new page, the "Open Page" simple action (or any redirect...() method in the context object) sends a redirect instruction to the browser, which then generates a GET request

– Use case● Links within a view to open the associated document but also

supply querystring information. Lets have a look...

Performance – Data Processing Optimization● In some cases, you just need to identify the event coming from the client

and then redirect to another page without any data processing. In this case, you don't need to apply the request values, validate them, update them... The best example for this is a Cancel button, when you just want to go back to the previous page

– Achieved by using the immediate property of the event handler● With this option set, phases 3, 4, and 5 are avoided, and the

data is not processed● Use this option when your event handler just

needs to do some server side processing,but redirect to a different page afterwards

● Use cases:

– Server side redirect action andavoiding processing of current form.Lets have a look...

Performance – Execution Mode Optimization● If only a portion of the page should be updated and processed, then the

EventHandler has an option called “Execution Mode” (execMode)

– Two values are possible: full (default), or partial● Partial restricts lifecycle execution to that control

– Another complimentary property is also available – execId● This allows a target control to be specified

– This allows Phases 2, 3, 4, and 5 to be processed on the submitting control, and any children referenced by the event handler

– If the control is within a repeat, then the repetition is not executed but only the required occurrence to reach the control is processed

– Use case● Executing a single document within a multi-document XPage.

Lets have a look...

Scalability – Data Cache Optimization● When a view is used, the server has to save the values displayed by

the page in case of a postback request.

– This ensures that the same data will be processed during the postback, and makes available the view data as it was when the page was rendered, regardless of what happened in the database since the initial request

● This has 2 side effects:– Data saved for the page consumes a large amount of memory– Extra processing as some objects cannot be kept in memory

between requests

Scalability – Data Cache Optimization

● If the data is not needed between requests (e.g. if there is no action using getColumnValue(), for example), then only the id and some other basic data, like the position, should be kept in memory

– This is achieved through a new View dataCache property:● The possible values are:

– full: the full data set should be retained in memory– id: only the id should be kept in memory between

requests. Postback access to values is not permitted● Use this option to save on memory and CPU processing● Use case

– A complex view vs. a simple view. Lets have a look...

Performance – Server Page Persistence● For the Restore View phase of the lifecycle, there is now a

property in 8.5.1 that allows you to control the persistence of XPages within the server

▬ By default, the last 4 XPages are always persisted to aid retrieval of a page▬ Improves server performance by reducing amount of processing

● Some applications will perform better based on how this property is set

▬ Low number of application users suits “Keep pages in memory”▬ High number of application users suits “Keep pages on disk”▬ Indeterminent number of application users suits “Keep the current page in memory”

● Use case▬ High vs.low throughput application

Lets have a look...

Integrating business logic● When making use of the scoped variables (sessionScope, ...), it is

better to use native JavaTM objects over JavaScript variables▬ Most beneficial when implementing caching mechanisms

▬ Prefer use of Java HashMap over JavaScript Array▬ Load Java objects into the HashMap

● Minimize instantiation of Java objects with the new operator, instead use static classes and methods

var utilityObject = new com.foo.logic.Utility();var result = utilityObject.processDocument(document.getId());

var result = com.foo.logic.Utility.processDocument(document.getId());

● Q&A

Less Is More

● When a control is instantiated new objects are created, these java new calls are expensive.

● More objects also means more memory usage● Consider breaking your page into following controls,

– Header– Navigation– Content (can have multiple e.g. edit / view)– Footer

Requesting Pages

● Use GET instead of POST when not submitting data

– i.e. Use direct links– GET requires less phases of the JSF lifecycle

● Partial Updates

– Partial updates make considerable less calls over the network.– Instead of request the complete page and possibly all its

associated files only a small portion of the the page is requested– Only that portion of the JSF Tree is processed

● partialExecute

Data Sources

● Declaring a data source has an overhead wheather the data source is used or not.

● Do not pre-emptively declare data sources

– Declare your data sources deep in your application just before you need them.

● In certain circumstances @Functions may be quicker

– e.g. Displaing the contents of a small view– @DBColumn can still be used with <xp:repeat>

When to Execute - # vs $

– Executed every time the page is rendered– Use for values that are likely to change

– Executed when the page is first loaded– Use for values that don't change

Use The Correct Tag

● <xp:div> should be used when you want a simple container.

● <xp:panel> is intended to contain editable data. If <xp:div>will do the same job use it.

● If you still want to use <xp:panel> but the content is only read-only be sure to set or compute the read-only attribute to true

● Use <xp:ScriptBlock> to insert computed client side JavaScript

Scopes

● viewScope

– Exists for the life a view (rendering of a page)● requestScope

– Exists for the life of a request ( can span pages)● sessionScope

– Exists for the life of user session i.e. Until they log-off, timeout or close browser

● applicationScope – Exists for the first loading of the application until a timeout

(default is 30 mins)

Network/Web Optimization's

● Goal

– Less requests– Less Bandwidth

● Reducing requests– Cache should be set for a long period or idenfity– Increment file names and links when a file changes

● Reducing Bandwidth – Smaller files

Network/Web Optimization's - Images

● Use correct file type depending on content

– JPEG for complexed detailed images– PNG/GIF for simple images, fonts, transparencies– GZip will not add any benefit.

● Size the image to size you intend to use– Resizing using html attributes height and width will delay the

rendering of your page– Images larger than necessary will waste bandwidth.

Network/Web Optimization's - CSS● Externalize styling so it can be cached and reused● Combine CSS files

– Less files reduces overhead on the network● Minify the CSS files

– Remove formatting and whitespace● Keep re-usablity in mind

– Simple identifiers are more reusable– Don't use complex identifiers

.classname div div div ul li span{...}– Avoid duplication

● GZip CSS files stored on disk

Network/Web Optimization's – CSS Sprites● Background images can be combined into one file.● The background image can be offset to correct position● Dramatically reduces number of requests for images.

Non-Optimized Site● 875ms to completely load the page

Optimized Site● 271ms to completely load the page● Exactly the same content in one third the time

Tony McGuckin - tony.mcguckin@ie.ibm.comMark Gargan - mark.gargan@ie.ibm.com

Related sessions:AD106 XPages Just Keep Getting Better Philippe Riand, Eamon Muldoon

AD107 Enhance your existing applications with XPages Steve Castledine, Stephan Wissel

AD108 XPages in the IBM Lotus Notes Client - A Deep Dive! Martin Donnelly, Teresa Monahan

AD110 Unleash the power of XPages! Philippe Riand, Maire Kehoe

AD111 Harnessing the Power of Server-Side JavaScript and Other Advanced XPage Techniques

Tim Tripcony, Stephan Wissel

BP207 Make Your XPage Apps "Pop!" with CSS and Themes Declan Lynch, David Leedy

SHOW112 How to Build an XPages Application from Start to Finish

Tim Clark, Matt White

Tony McGuckin - tony.mcguckin@ie.ibm.comMark Gargan - mark.gargan@ie.ibm.com

Thank You!

Merci!

Grazie!

Gracias! M Goi!

Tak!Dank U!

Daarim!

Danke!Dekuji!

Go raibh maith agaibh!

The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication 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.

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. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. 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.

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.

IBM, the IBM logo, Lotus, Lotus Notes, Notes, Domino, Quickr, Sametime, WebSphere, UC2, PartnerWorld and Lotusphere are trademarks of International Business Machines Corporation in the United States, other countries, or both. Unyte is a trademark of WebDialogs, Inc., in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

All references to Renovations refer to a fictitious company and are used for illustration purposes only.

Ad109 - XPages Performance and Scalability

Technology