Understanding the XPages architecture is key to building performant scalable enterprise-ready 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.
Exploring the Future Potential of AI-Enabled Smartphone Processors
Ad109 - XPages Performance and Scalability
1. AD109: XPages Performance & Scalability
Tony McGuckin | IBM Software Engineer, XPages Runtime
Mark Gargan | IBM Software Engineer, Quickr Domino
2. Abstract
Understanding 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.
3. 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
3
4. 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
▬ ...
4
5. Who are we?
● Mark Gargan
▬ IBM Software Engineer, Dublin Software Lab, Ireland
5
6. Agenda
● Who are we?
● What's this session about?
● Understanding the problem
● XPages – Optimizing application execution within the server
● XPages – Optimizing application design and browser output
● Q&A
6
7. 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!
7
8. 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
8
9. 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)
9
10. 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
10
11. 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
11
12. 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
12
13. 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
13
15. 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...
15
21. 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
21
22. 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...
22
23. 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 and
avoiding processing of current form.
Lets have a look...
23
24. 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...
24
25. 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
25
26. 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...
26
27. 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...
27
28. 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());
28
29. 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
29
30. 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
30
31. 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
31
32. 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>
32
33. 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
33
34. 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
34
35. 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)
35
36. 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
36
37. 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.
37
38. 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
38
39. 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.
39
41. Optimized Site
● 271ms to completely load the page
● Exactly the same content in one third the time
41
42. Q&A
Tony McGuckin - tony.mcguckin@ie.ibm.com
Mark Gargan - mark.gargan@ie.ibm.com
42
43. 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 Tim Tripcony, Stephan Wissel
Other Advanced XPage Techniques
BP207 Make Your XPage Apps "Pop!" with CSS and Themes Declan Lynch, David Leedy
SHOW112 How to Build an XPages Application from Start to Tim Clark, Matt White
Finish
43
44. Tak! Grazie!
Thank Dekuji! Dank U!
You! Danke! Go raibh maith
agaibh!
Daarim!
Gracias! M Goi! Merci!
Tony McGuckin - tony.mcguckin@ie.ibm.com
Mark Gargan - mark.gargan@ie.ibm.com
44