Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "XPages Performance Masterclass Survive in the fast lane on the Autobahn! Howard Greenberg, TLCC Ulrich Krause, BCC GmbH."— Presentation transcript:

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


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

Similar presentations


Ads by Google