1. XPages Performance Masterclass Survive in the fast lane on the Autobahn!
Howard Greenberg, TLCC
Ulrich Krause, BCC GmbH

2. About: Ulrich Krause
Administrator /Developer since 1993
Senior Software Architect at BCC, Germany
OpenNTF Contributor
IBM Champion 2011/2012/2013/2014
Blog
Mail

3. About: Howard Greenberg
Notes/Domino developer, admin, instructor since 1993
Before that was at IBM for 11 years in the PC Company
Partner at TLCC, a provider of courses for Notes/Domino
And lots of XPages courses!
Some are even FREE!
IBM Champion 2012/2013/2014
Host a great monthly webinar series!
Mail

4. What factors affect Performance? JSF Lifecycle
Agenda
What factors affect Performance?
JSF Lifecycle
Partial Update / Partial Execute
Tools
Coding Factors
ViewNavigator vs. GetItemValue
SSJS vs. Java
Stringbuilder
Questions???

5. XPages Request

6. Hardware
The hardware used has a significant influence on performance. There are 3 key elements:
CPU
Main Memory
Hard Disk

7. Network Latency Bandwidth
Time taken for data transmission between multiple computers on a network
Bandwidth
Rate of transmission of data
Greater Bandwidth + Lower Latency = Better Connection

8. Client & Browser
Hardware
How many data requests / responses are transmitted
How much data is transferred (size)
Caching of resources
How much CSJS runs
Size / complexity of the CSS
Complexity of the site structure

9. Limiting factors on performance
Browser / HTTP server
Network latency – distance/time to server.
Bandwidth – size of files.
Browser limits on concurrent downloads
IE7 allows 2 downloads, IE8 allows 6
HTTP Server / App Server
HTTP Server JVM heap size & garbage collector
CPU time, competition between threads, gives slower response times
Threads, limited to 40 by default

10. Limiting factors on performance
App Server / Domino context
Read design elements from the NSF (XPage .class files, form structure, etc)
Backend API calls may be expensive, especially for large data sets
Design elements may be network requests

11. Limiting factors on performance
Servlet / Lifecycle
Restore control tree – file system read. Control tree locking – no concurrent access
Rendered re-evaluated for every control for most phases
Browser/Client JavaScript/Dojo
Inline JavaScript blocks insertion of later HTML elements into the DOM tree
Dojo does AJAX requests for .js files for dojo modules that are not loaded

12. General Performance Options
notes.ini
HTTPJVMMaxHeapSizeSet=1
HTTPJVMMaxHeapSize=256M
Should be set to ¼ of the available RAM
Domino Administrator
HTTP server Disable Logging
HTTP server thread count defaults to 40
link to IBM article

13. General Performance Options (cont.)
Debugging enabled in notes.ini ?
JavaEnableDebug=1
JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=8000
JavascriptEnableDebug=1

14. Reducing Memory Utilization
xsp.persistence.mode=
Defines the persistence mode for the JSF pages
file: All the pages are persisted on disk
fileex: All the pages are persisted on disk except the current one, which stays in memory
<else>: All the pages stay in memory (tree mode)
Change the server page persistence setting to keep the current page in memory.
Strictly speaking, keeping all pages in memory provides the best performance, but it tends to be downright wasteful of memory.
When only the current page is kept in memory, as a user navigates from page to page (as opposed to firing events against the page they're already on... even if it's a full refresh event), it serializes the state of the previous page to disk.
If a subsequent event is fired against that previous page, then that page's state is retrieved from disk and loaded back into memory. 
But this scenario only occurs if the application loads a new page in a new window or tab, and the user later switches back to the original window and interacts with it again. In typical navigation scenarios, once the user has opened a new page, the previous page instance no longer exists... even if they navigate back to the same page again, it's a new instance  of that page.
Hence, keeping all pages in memory essentially guarantees at least a temporary memory leak.
All of that storage is eventually released, of course, but in the meantime the server is consuming memory it will never need again that would be better served storing whatever you're explicitly caching in scope variables.

15. JavaScript/CSS Aggregation
Groups many DOJO, CSS / JS files into a single file
Less requests from the browser to the server
Performance improvements on networks with high latency
Enhanced performance parsing CSS / JS
Fewer connections to the server
On the Server: xsp.properties:
xsp.resources.aggregate=true
JavaScript/CSS Aggregation feature
For performance reasons, the XPages runtime now features a new option that dynamically aggregates multiple Dojo modules, or multiple CSSs into a single file. This results in the following performance improvements:a decrease in requests sent from the browser to the server
an increase in user performance, particularly in the context of networks with high latency
an increase in the speed of JS/CSS parsing from the browser
the freeing up of server connections to fulfill other requests
As an extreme example of the saving, let's say the XPages Extension Library is using the page DWA_ListView.xsp. Without the aggregator enabled, 82 requests are made to the server. With the aggregator enabled, the count decreases to 6 requests, including the Ajax request that gets the data. Also, a test run on processing time might see changes from ~4 sec to ~800 ms.
To allow you to actvate this option, XPages now feature a new runtime option, which can be set in xsp.properties (database or server level). This option is xsp.resources.aggregate=true
It can also be set in Domino Designer from the Application Properties - XPages tab by checking the Use runtime optimized JavaScript and CCS resources option.

16. JavaScript/CSS Aggregation

17. New Feature in Notes / Domino 8.5.3 Works on Server and Client
XPages PreLoad
XPagesPreload=1
New Feature in Notes / Domino 8.5.3
Works on Server and Client
Java classes from the XPages runtime plug-ins loaded from a fixed list of runtime classes ( 435 in ND )
com.ibm.xsp.core, common utility, JS wrapper, FSF runtime classes
Java classes referenced in *-faces.config.xml
XPages control renderer, data sources, complex types

18. XPagesPreloadTrace=1 ( as of 9.0.1 )
XPagesPreloadDB=Server!!Db.nsf/XPage.xsp,myLocalDb.nsf
XPagesPreloadTrace=1 ( as of )
Works at the application level
The application is loaded on the client / server startup into memory
This happens even when the application is first opened in the browser
Add this setting to your notes.ini file: XPagesPreloadTrace=1 Next time you start your Domino server you should see the preload info appear on the console. You can also verify that the modules are loaded with a 'tell' command. A sample of all this is below. Looks like that original output was not intended to go to the Domino console in production builds by default. That variable was added in to control the behaviour: [12EDC: C] 27/11/ :32:11 XSP Command Manager initialized [12EDC:002C-EE64] 27/11/ :32:11 HTTP JVM: Preloading XPages classes took 349ms [12EDC: C] 27/11/ :32:12 HTTP Server: Started [12EDC: ] 27/11/ :32:12 HTTP JVM: Preloading JSF config took 477ms [12EDC:003B-13AFC] 27/11/ :32:12 HTTP JVM: Preloading NSF chp08ed2.nsf module took 1002ms [12EDC:003F-133AC] 27/11/ :32:12 HTTP JVM: Preloading NSF blankapp.nsf module took 1338ms [12EDC: C] 27/11/ :32:14 HTTP JVM: Preloading NSF chp09ed2.nsf/dtProfile.xsp module took 2569ms > tell http xsp show modules [12EDC: C] 27/11/ :32:34 Default Http Registry Module [12EDC: C] 27/11/ :32:34 OSGI WebContainer Bridge Service [12EDC: C] 27/11/ :32:34 XSP Resources [12EDC: C] 27/11/ :32:34 blankapp.nsf [12EDC: C] 27/11/ :32:34 chp09ed2.nsf [12EDC: C] 27/11/ :32:34 chp08ed2.nsf Feedback response number MDOY9DXPUU created by Martin Donnelly on

19. XPages PreLoad (cont.)
For each entry in the notes.ini variable, an XPage URL is generated and sent to the server
The application is loaded, and the HTML generated
The XPages runtime discards the HTML, but retains the application in memory

20. Scoped Variables applicationScope sessionScope
Are visible for all users of one application
Expires some time after the last user used an applicationScope variable
applicationScope variables are NOT persistent forever
sessionScope
Is valid through the session of the current user
A user session expires after some time of inactivity
Uses don't have access to the sessionScope variables of other users
First and foremost, become intimately familiar with the so-called "scope variables". The nature and use of these are documented in detail elsewhere, so I won't belabor that here. But the better you understand what information is appropriate to store in each scope - and that you can store complex object structures, not just "string-to-string" mapping - and the more you take advantage of this, the faster the application's response will be. This is because you're limiting disk I/O as much as possible... the more frequently the application can just pull whatever data the user is requesting from RAM, instead of querying the database every time, the faster the application will be. This is why you want lots and lots of RAM. :) Of course, you don't want to be gratuitous with your memory storage, which is why it's crucial to understand which scope is appropriate for which type of data... when you get the hang of this, Domino will clean up these memory caches for you automatically.  If you find that you're running out of memory, but you're confident your scope storage is reasonably optimized, tweak the application properties to clear the application scope periodically. The higher the frequency you set, the more you can cache in all the scopes without bursting the heap... but if you find you're needing to set this to a frequency of less than an hour, revisit what you're actually storing, because it's probably out of control.

21. Scoped Variables (cont.)
viewScope
Is visible for views on the current page only.
Useful for transporting a search query to a view.
requestScope
Is valid through one request of the current user.
That includes refreshing of a page.
First and foremost, become intimately familiar with the so-called "scope variables". The nature and use of these are documented in detail elsewhere, so I won't belabor that here. But the better you understand what information is appropriate to store in each scope - and that you can store complex object structures, not just "string-to-string" mapping - and the more you take advantage of this, the faster the application's response will be. This is because you're limiting disk I/O as much as possible... the more frequently the application can just pull whatever data the user is requesting from RAM, instead of querying the database every time, the faster the application will be. This is why you want lots and lots of RAM. :) Of course, you don't want to be gratuitous with your memory storage, which is why it's crucial to understand which scope is appropriate for which type of data... when you get the hang of this, Domino will clean up these memory caches for you automatically.  If you find that you're running out of memory, but you're confident your scope storage is reasonably optimized, tweak the application properties to clear the application scope periodically. The higher the frequency you set, the more you can cache in all the scopes without bursting the heap... but if you find you're needing to set this to a frequency of less than an hour, revisit what you're actually storing, because it's probably out of control.

22. Caching with Application Scope
Last slide for Ulrich, Howard takes over

23. JSF Life Cycle - Post Request Response
Restore View
Restore component tree
Events:
afterRestoreView
Apply Request Values
Copy data to Editable controls
Process Validations
Validations
Converters
Update Model Values
Move values to data source
Invoke Application
Application logic
onClientLoad (XPage, etc)
on… events of button, etc.
Render Response
Convert to HTML, etc.
beforeRenderReponse
afterRenderResponse
Request
Howard’s section, plan on 20 min max, preferably 15…
XPages are based on Java Server Faces. This is what happens when an XPages is submitted to the server
Restore view – loads component tree into memory. Components are the controls on the page.
Apply Request values - takes the editable values from the web page and applies them to the components, for example a value in an edit box control.
Process validation – the validators run for every control along with the converters like the number or date converters, if there is a validation error jump to the render response phase
Update Model values – the data is applied to the underlying data source, ie, written to the Domino document data source variable
Invoke application – here the application logic happens, this is the onclick, etc. events of buttons and other controls
The events on the Xpage occur during the different phases.
To illustrate this we have a database with a phase listener. This will issue a print statement to the console when each phase starts and ends. Tony’s video/demo from OpenNTF
SHOW lifecycle1 and how this is designed.
Response

24. Lifecycle1 XPage – Initial Page Load
Render Response
Rendered property for id: label1
Label property for id: label1
Rendered property for id: inputText1
Default value property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
values property for id: comboBox1
Rendered property for id: computedField1
Value property for id: computedField1
Rendered property for id: computedField2
Value property for id: computedField2
This is what happens when an Xpage is first loaded, otherwise known as a GET request. No data had to be converted, validated, or applied so just the RenderResponse phase is run.

25. Lifecyle1 – Submit (Full Update)
Restore View
Apply Request Values (8)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Process Validations (11)
Validation for inputText1
Default value property for id: inputText1
values property for id: comboBox1
Update Model Values (8)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Invoke Application (1)
OnClick event for id: button1
Render Response (11)
Label property for id: label1
values property for id: comboBox1
Value property for id: computedField1
Value property for id: computedField2
Now, we entered some data on the page and submitted it via the submit button. Note that all the phases run. The rendered properties run multiple times!
Review each phase.
Invoke Application runs the onclick event of the button
Adds up to 39 SSJS calls! Imagine if in each rendered property we did to determine if the control should appear?
Now let’s look at how to optimize our Xpage!
39 SSJS Calls

26. # is Compute dynamically
When to Execute - # vs $
<xp:label id="label1">
<xp:this.value>
<![CDATA[#{javascript:return “My Label”;}]]>
</xp:this.value>
</xp:label>
# is Compute dynamically
Executed every time the page is rendered
Use for values that are likely to change
$ is Compute on Page Load
Executed when the page is first loaded
Use for values that don't change
At the top of the SSJS editor is the on page load and dynamic radio button. This controls if this SSJS will run every time the page is submitted or just on page load.
In the source view the onpageload is shown with a $ and dynamic is a #
Whenever possible use the on page load, it prevents all those rendereds from getting computed multiple times.
This is very critical in a repeat or data table type control since each property would get computed for each line in the repeat.
Review the LifeCycle2 xpage and then “Let’s see the savings.”

27. Lifecyle2 – Submit (Full Update) - On Page Load
Restore View
Apply Request Values
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Process Validations (2)
Validation for inputText1
Default value property for id: inputText1
values property for id: comboBox1
Changed all Rendered and Values (comboBox) to only compute on Page Load
Update Model Values
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Invoke Application (1)
OnClick event for id: button1
Render Response (3)
Label property for id: label1
values property for id: comboBox1
Value property for id: computedField1
Value property for id: computedField2
We took the previous Xpage and changed all the rendered properties to on page load. Also, the values property for the combobox was changed too.
Quite a significant savings!
6 SSJS Calls, saved 33

28. But I need dynamic Rendering!
Options for dynamically computing the Rendered:
Scoped variables
Still get calculated but do the heavy lifting once and then read the scoped variable in the Rendered property
DataContexts
Compute a value at the Xpage or Panel level once
Refer to the value using EL (much faster than SSJS)
Of course this may not work for all your controls. What else can we do?
One option is scoped variables, these are going to be present in memory. You could compute the scoped variables in the beforePageLoad event and then use those to control the rendered properties. Then each rendered does a quick call to the scoped variable instead of the logic to display the control.
Another option is Datacontexts. These can be bound to the Xpage or panel and then referred to with the EL language. There is no need to parse out the SSJS.

29. Can be thought of as global variables
DataContext
Can be thought of as global variables
Value can be computed dynamically or on page load
Warning: Computing dynamically has performance impact
Can be scoped to any level that a data source can
XPage, Custom Control or Panel
Set a dataContext in a panel in a repeat control to avoid multiple references to a NotesDocument's item
Can be referenced using EL
Benefit: Not having to go through the SSJS parser
Review DataContext XPage and show how it was setup.
This is very useful in a repeat control that accesses an item in a document multiple times in each line. Use a datacontext to access the value and then refer to the value in the datacontext with EL.

30. Be careful binding data context variables dynamically
DataContext - Pitfall
Be careful binding data context variables dynamically
They will be recomputed multiple times, even when in partial execution mode and if they are not in use (six times!)
Apply Request Values
Process Validations
Update Model Values
Invoke Application
Twice in Render Response!
If computed on page load then only computed once on page load
See Paul Withers blog entry to learn how to set a data context value via code
One issue with dataContexts is that if they recompute dynamically they get recomputed multiple times in the JSF lifecycle, just like the rendered does.
One workaround is to set the dataContext programmatically, I have included a link on this slide to Paul Withers blog for a way to set the dataContext via code.

31. Partial Refresh vs. Partial Execution?
Partial Refresh (Update)
Computes entire XPage, only sends back what is in the partial refresh id (refreshId)
Partial Execution
Only calculates what is in the area specified (execId)
WAKEUP – if you don’t know the difference between Partial Refresh (what most folks call it, aka update) and Partial execute stop what you are doing and listen for five minutes…
Partial Refresh still computes the entire JSF Lifecycle but only sends back the area in the Partial Refresh.
Partial Execution only calculates the area specified but sends back everything.
Show PartialRefresh page and button event. RUN the Xpage to show before moving to next slide. Note how the time only changes for the computedField in the yellow area.

32. Partial Refresh Demo - Results
Restore View
Apply Request Values (8)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Process Validations (11)
Validation for inputText1
Default value property for id: inputText1
values property for id: comboBox1
Update Model Values (8)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Invoke Application (1)
OnClick event for id: button1
Render Response (2)
Label property for id: label1
values property for id: comboBox1
Value property for id: computedField1
Value property for id: computedField2
Here is our original Xpage with partial refresh enabled for that one area. Note there was not much savings? However, only the area in yellow was sent back to the browser, that is a savings and also a better ui
Only Savings were here!
30 SSJS Calls, saved 9

33. Partial Refresh Pros and Cons
Reduced control processing in the render response phase
Smaller response from server
Means reduced network usage
Better UI experience
Rest of the page is still visible while waiting for a response
Cons
Controls like computed fields outside refresh area don’t refresh
Be careful turning this on for a completed XPage (TEST!)
Can only update one area (one id)
Workaround on Tim Tripcony blog here
There can be some issues with partial refresh to be aware of.
You can only update one area, but see the link on this page from Tim Tripcony’s blog for a workaround suggestion.
Now let’s look at Partial Execution with the PartialExecution xpage.
Note how the button only executes the panel in yellow. Also, note the button has to be in the partial exec area so the onclick event in the button will work. We are still doing a full update here.
WHEN DOING THE DEMO PUT A VALUE IN THE EDITABLE FIELD!!!!
RUN the Xpage and point out the times change for both. The RenderResponse still runs for ALL controls since it is doing a FULL UPDATE.

34. Partial Execution Demo - Results
Restore View
Apply Request Values (1)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Process Validations (1)
Validation for inputText1
Default value property for id: inputText1
values property for id: comboBox1
16 SSJS Calls
Saved 24
Update Model Values (1)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Invoke Application (1)
OnClick event for id: button1
Render Response (12)
Label property for id: label1
Default value property for id: inputText1
values property for id: comboBox1
Value property for id: computedField1
Value property for id: computedField2
We saved some significant processing times in all the phases except RenderResponse. It still does everything there.

35. Partial Execution Pros and Cons
Reduced processing in the 3 data-processing phases
Cons
Control with onClick event has to be inside the execId area
Editable values outside of the executed area do not get submitted/updated (reset to default values)
Existing XPages need analysis/testing before using this
Current onclick events might refer to controls where the data is not submitted
ExecMode available in 8.5.1
Have to use source to enter ExecId (in 8.5, 9.0 has Designer UI)
A few gotchas with this. Make sure the button or other control that kicks off the partial exec is in the partial exec area.
This is not available in (please tell me you don’t use that!) In pre 9.0 you have to enter the execId in the source panel. You can enable in the Designer UI. Be sure to set this or it will only partially execute the event handler only and NOTHING else.
Remember, that partial exec. did not do the apply request values so any data the user entered outside the partial exec. area is lost.
Partial Refresh and Execution work very well together. Show Xpage…

36. Partial Refresh AND Execution Demo - Results
Restore View
Apply Request Values (1)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Process Validations (1)
Validation for inputText1
Default value property for id: inputText1
values property for id: comboBox1
Update Model Values (1)
Rendered property for id: label1
Rendered property for id: inputText1
Rendered property for id: label2
Rendered property for id: comboBox1
Rendered property for id: computedField1
Rendered property for id: computedField2
Invoke Application (1)
OnClick event for id: button1
Render Response (2)
Label property for id: label1
values property for id: comboBox1
Value property for id: computedField1
Value property for id: computedField2
Note the savings now….
6 SSJS Calls, saved 33

37. disableValidators= true
All phases (1-6) occur
Turns off all validators
Converters continue to work
Items in documents will be updated
Another option is to turn off the validators in the Process Validations phase. The converters will continue to happen. This is not only a performance trick but also a way to send updated data to the server before actually saving the data to allow controls on the page to be updated after the user entered some data.
Restore View
Apply Request Values
Process Validations
No Validators get executed here!
Update Model Values
Invoke Application
Render Response

38. Immediate = true JSF Lifecycle processes only phases (1, 2, 6)
No data processing
Items in documents are not updated
Onclick event handler scripts and render response calculations are performed
Another option is to use the immediate setting to stop process validaitons, update model values, and invoke application phases. The data sources are NOT updated and data is not validated or converted.
Restore View
Apply Request Values
Process Validations
Update Model Values
Invoke Application
Render Response

39. Using the loaded Property
Loaded = true
Created in component tree and memory
Loaded = false
Control is not created
Can never be rendered or accessed
Saves memory too
One thing that traps a lot of developers is using loaded. This will HELP your perfomance but might have side effects. If a control is NOT loaded it is not available to access in your code and you can’t display that control later after the page loads.
Just be aware…

40. Life Cycle Performance Suggestions
Most properties, like CSS “style” are only computed in the RenderResponse phase
Watch and minimize:
Rendered property (when dynamic)
Computed multiple times!
Use dataContexts or scoped variables when able
Use both Partial Refresh (Update) and Partial Execute when able
Summarizing what I talked about with the lifecycle and the related settings.
Most properties are not like the rendered, they will only compute in the renderResponse like the CSS style or styleClass.
Minimize your code in the rendered properties. Do the heavy lifting in dataContexts or scoped vars
Use Partial Refresh and exec when able

41. Watch Out for @DbLookup
@DbLookup about 3-4 times slower than SSJS
res "phone");
vs.
doc = vw.getDocumentByKey(names[i], true); res = doc.getItemValueString("phone");
Five lookups repeated 100 times
@DbLookup averaged about 1728ms
getDocumentByKey averaged 510ms
not tested
Howard last slide, Ulrich takes over

42. Use correct file type depending on content
Images
Use correct file type depending on content
JPEG for complex and detailed images
PNG/GIF for simple images, fonts, transparencies
Use the HTML <img> tag “width” and “height” attributes
For faster HTML layout in the browser
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

43. Image Sprites Use CSS Image Sprites
If you have multiple small images, make a single larger image containing the smaller images
Use CSS to display only the relevant subset image at a location in the page
For semantically significant sprites, provide an accessibility “title” attribute (as sprites don't use the IMG “alt” attribute, but you still want to assist blind users)
There's no specific XPages support for sprites, but they're used in the XPages OneIU themes

44. CSS Image Sprite Sample

45. XPages based Application
XPages Toolbox
XPages based Application
Runs on the Domino server or the Notes client
An NSF needs to be installed on the server/Notes client
A profiler jar file should be added to the JVM launch options
Measures CPU performance and memory allocation
Available from OpenNTF.org
Free open source project
Extended in to support backend classes profiling

46. XPages Toolbox
Explain the difference between CPU and WallTime

47. Generate a heap dump of the JVM running in the HTTP task
XPages Toolbox
Generate a heap dump of the JVM running in the HTTP task
A button in the XPages profiler generates the heap dump
From the Domino console
tell http xsp heapdump (triggers com.ibm.jvm.Dump.HeapDump())
tell http xsp javadump (triggers com.ibm.jvm.Dump.JavaDump())
Analyze the heap dump using the Eclipse memory analyzer

48. Heapdump / Javadump Analyzer

49. Task Manager and/or Process Explorer
More Tools
Print statements
In rendered/visible computations to see how often executed
print("panel2 evaluating rendered property");
In the XPages root control events:
before/afterPageLoad, afterRestoreView, before/afterRenderResponse
Custom control root events:
before/afterPageLoad
In the document data source events:
queryNewDocument, postSaveDocument, etc.
Task Manager and/or Process Explorer
Shows CPU usage & process memory usage as it happens

50. Browser developer tools
More Tools
Browser developer tools
for watching network transactions, partial updates, response times
BROWSER: Firebug, Developer Tools
XPiNC: FirebugLite from ExtLib
Java / Javascript Debugging
Degrades performance but can inspect objects
Use the Eclipse Java debugger
In Domino\notes.ini add these 2 options:
JavaEnableDebug=1
JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=8000

51. Optimisation – Step by Step

52. Step1: Original Code from sample
Creates a NotesDocumentCollection
Creates a JSON String from the documents in the collection

53. Step1: Result

54. Step 2: Read UNID from item
Like Step1, but UNID is written to an item when document is saved

55. Step2: Result

56. Step3: Create JSON in document
Instead of reading the values from the document‘s items, we store the JSON data when the document is saved

57. Step 3: Result

58. Step 4: Create JSON in a view

59. Step 4: Result

60. StringBuilder vs String.concat
To concat two strings, you only need a +
Each operation creates a new string object, adds the new string to the object. Discards the object
The longer the string, the longer it takes .
Use the + with 2 or 3 strings
Use a StringBuilder if you handle tons of data.

61. StringBuilder vs String.concat
Tons of data  Use StringBuilder
+ und concat are easy to use, but not always the best way

62. Step 5: StringBuilder

63. Step 5: Result

64. Step 6: JAVA …
Xpage SSJS Code
Java Code

65. Step 6: Result

66. Homework Time – Further References
IBM article on JSF (non XPages)
Paul Withers blog (each link below is different)
Part 1, Part 2, Part 3
Tony McGuckin’s Video - XPages Master class
4 videos plus sample applications

67. Q & A