670 likes | 837 Views
XPages Performance Masterclass Survive in the fast lane on the Autobahn!. Howard Greenberg, TLCC Ulrich Krause, BCC GmbH. About: Ulrich Krause. Administrator /Developer since 1993 Senior Software Architect at BCC, Germany OpenNTF Contributor IBM Champion 2011/2012/2013/2014
E N D
XPagesPerformance MasterclassSurvive in the fast lane on the Autobahn! Howard Greenberg, TLCC Ulrich Krause, BCC GmbH
About: Ulrich Krause • Administrator /Developer since 1993 • Senior Software Architect at BCC, Germany • OpenNTF Contributor • IBM Champion 2011/2012/2013/2014 • Blog http://www.eknori.de • Twitter @eknori • Mail ulrich.krause@eknori.de
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! • Twitter @TLCCLtd • Mail howardg@tlcc.com
Agenda • What factors affect Performance? • JSF Lifecycle • Partial Update / Partial Execute • Tools • Coding Factors • ViewNavigator vs. GetItemValue • SSJS vs. Java • Stringbuilder • Questions???
Hardware • The hardware used has a significant influence on performance. There are 3 key elements: • CPU • Main Memory • Hard Disk
Network • Latency • Time taken for data transmission between multiple computers on a network • Bandwidth • Rate of transmission of data • Greater Bandwidth + Lower Latency --------------------------------= Better Connection
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
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
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
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
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
General Performance Options (cont.) • Debugging enabled in notes.ini ? • JavaEnableDebug=1 • JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=8000 • JavascriptEnableDebug=1
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)
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
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 8.5.3 ) • 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
XPages PreLoad • XPagesPreloadDB=Server!!Db.nsf/XPage.xsp,myLocalDb.nsf • XPagesPreloadTrace=1 ( as of 9.0.1 ) • 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
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
Scoped Variables • applicationScope • 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
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.
JSF Life Cycle - Post Request Response
Lifecyle1 – Submit (Full Update) 39 SSJS Calls
# 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 When to Execute - # vs $ <xp:label id="label1"> <xp:this.value> <![CDATA[#{javascript:return “My Label”;}]]> </xp:this.value> </xp:label>
Lifecyle2 – Submit (Full Update) - On Page Load Changed all Rendered and Values (comboBox) to only compute on Page Load 6 SSJS Calls, saved 33
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) But I need dynamic Rendering!
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
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
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)
Partial Refresh Demo - Results Only Savings were here! 30 SSJS Calls, saved 9
Partial Refresh Pros and Cons • Pros • 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
Partial Execution Demo - Results 16 SSJS Calls Saved 24
Partial Execution Pros and Cons • Pros • 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)
Partial Refresh AND Execution Demo - Results 6 SSJS Calls, saved 33
disableValidators= true • All phases (1-6) occur • Turns off all validators • Converters continue to work • Items in documents will be updated
Immediate = true • JSF Lifecycle processes only phases (1, 2, 6) • No data processing • Items in documents are not updated • Onclick event handler scripts andrender response calculations are performed
Using the loaded Property • Loaded = true • Created in component tree andmemory • Loaded = false • Control is not created • Can never be rendered or accessed • Saves memory too
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
Watch Out for @DbLookup • @DbLookup about 3-4 times slower than SSJS • res = @DbLookup(db,"CustomersByNameView",names[i], "phone"); vs. • doc = vw.getDocumentByKey(names[i], true);res = doc.getItemValueString("phone"); • Five lookups repeated 100 times • @DbLookup averaged about 1728ms • getDocumentByKey averaged 510ms • Other @Functions not tested
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
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
CSS Image Sprite Sample http://www.w3schools.com/css/tryit.asp?filename=trycss_sprites_img
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 • http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=XPages%20Toolbox • Extended in 8.5.2 to support backend classes profiling
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 • http://www.eclipse.org/mat/ • http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html
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
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