Expert Tips and Tricks to Optimize the Performance of Your XPages Applications Bruce Elgort Elguji Software

Transcription

1 Expert Tips and Tricks to Optimize the Performance of Your XPages Applications Bruce Elgort Elguji Software 2012 Wellesley Information Services. All rights reserved.

2 In This Session... Users expect that applications are fast and responsive Isn t it funny how you only hear from them when they are slow and poorly designed XPages does all this for me, right? Nope. XPages gives us a powerful set of development tools right out of the box, however They sometimes don t perform as well as we had hoped Or we used XPages when a classic Domino application could have done the trick This session is designed to help developers optimize the performance of their XPages applications 1

3 What We ll Cover Things to consider when moving applications to XPages Understanding the JSF lifecycle and how it relates to XPages application design Development best practices for performance and scalability How to identify application bottlenecks using the OpenNTF XPages Toolbox Third-party tools to help profile your applications performance Wrap-up 2

4 XPages Application Design Considerations When should you: Migrate a Notes/Domino application to XPages? Avoid developing/migrating applications to XPages? Consider a hybrid approach? 3

5 Migrating an Application to XPages Consider migrating an application to XPages if: It s an active application that brings value to the business Functionality can be moved to the browser without much disruption and/or retraining It is not required to be used offline Notes only applications that now require Web browser access The applications need a facelift and/or require new functionality 4

6 Avoid Using XPages You may want to avoid using XPages if: Notes encryption is required The app depends on COM for calling other applications such as Word or Excel Makes heavy use of rich text Integration with calendaring and scheduling is required You have stable complex applications that are mission-critical and running the business You have applications that are better suited for a Notes client user experience 5

7 When to Consider a Hybrid Approach A hybrid approach is one that utilizes classic Notes and Domino design elements, as well as ones developed using XPages Consider a hybrid approach when: You have Notes client apps that require Web browser and/or mobile support yet still require use of the Notes client You need to add REST services, report generation, or other services using XPages XAgents When you are first starting to learn XPages When only a subset of features are needed from the Web and/or mobile device 6

8 What We ll Cover Things to consider when moving applications to XPages Understanding the JSF lifecycle and how it relates to XPages application design Development best practices for performance and scalability How to identify application bottlenecks using the OpenNTF XPages Toolbox Third-party tools to help profile your applications performance Wrap-up 7

9 Understanding the JSF Lifecycle XPages is built on the JavaServer Faces framework It is important to understand the principles of this framework Stateful Web application architecture Component-based architecture Every tag has a server-side object representation Saving and restoring state Validation Rendering the tags/markup to the client Uses a six-phase life cycle that is extended by XPages 8

10 The 6 Phase JSF Request Processing Lifecycle 1. Restore View Retrieves the JSF view for the request 2. Apply Request Values Updates the JSF components to update their state based on values from the current request 3. Process Validations Validators invoked 4. Update model values Application data is updated with new values. Values are written to the Domino back-end document during this phase. 5. Invoke applications Application logic executed 6. Render response Generates the response and saves the state of the view 9

11 More on the JSF Lifecycle Phases and What They Do Phases 1 and 6 are system-level phases They are going to happen no matter what we do to our code Phases 2, 3, 4, and 5 are application-level phases These phases are something we as developers can use to our advantage By understanding how we can tweak our XPages objects to make more efficient use of the JSF lifecycle We will explore how your XPages can skip some of the six phases which in turn reduce CPU utilization processing and increase speed 10

12 The JSF Lifecycle 11

13 The Link Control and the JSF Lifecycle Let s start off by looking at the link control The link control is used to place a hypertext link on an XPage or in a custom control When you place the link control on your XPage and use a simple action to set the link you will see this in your XPage markup <a id="view:_id1:link1" href="#" class="xsplink">link</a> When you inspect what the browser is doing when the link is clicked you will see that the browser is issuing a POST request to the server This is using phases 2-5 of the JSF lifecycle and is a more expensive operation An extra trip is being made to the server to resolve the # in the link 12

14 The Link Control and the JSF Lifecycle (cont.) Changing the simple action to a defined page in the link properties will now generate this code <a id="view:_id1:link1" href="/xpagesplay.nsf/contact.xsp" class="xsplink">link</a> This will eliminate the need for: A round trip to the server (POST) is now bypassed as are phases 2-5 of the JSF lifecycle Use direct links whenever possible These will generate GET requests Save CPU time Generate a snappier user experience 13

15 What We ll Cover Things to consider when moving applications to XPages Understanding the JSF lifecycle and how it relates to XPages application design Development best practices for performance and scalability How to identify application bottlenecks using the OpenNTF XPages Toolbox Third-party tools to help profile your applications performance Wrap-up 14

16 The Read-Only Property Setting the read-only property of a Panel in Domino Designer 15

17 The Read-Only Property (cont.) Use Panel controls where no server-side JavaScript or simple actions are contained in the panel that don t require processing Panel controls generate HTML divs which are used to place other components within Set this to true in the Properties panel Other considerations: The other thing you should consider is not using the Panel core control but rather an HTML div instead This is also true for any other HTML element that doesn t require any processing Remember that only <xp:> tags are processed during the JSF lifecycle Setting read-only to true skips JSF phases

18 The Immediate Property This does not validate or update any data No server validation will occur No further processing of the XPages component tree will occur Just do what I say immediately and Cancel! Typically used on a Cancel button Set the value to true <xp:button value="cancel" id="button2"><xp:eventhandler event="onclick" submit="true" refreshmode="complete" save="false" immediate="true"></xp:eventhandler></ xp:button> Setting the immediate property to true skips JSF phases

19 The Immediate Property (cont.) Here is our Cancel button in Domino Designer showing the Do not validate or update data option is checked This sets the value to true in the XPage XML source 18

20 Partial Refresh A radio button under a controls Server Options that allows you to select the target component that will be refreshed Reduces the amount of HTML markup that must be processed and emitted Less HTML and other elements means that the application is more responsive The entire page does not have to be reloaded Makes Phase 6 (Render response) of the JSF lifecycle very fast and efficient Only the selected/component branch of the JSF tree is updated There may be some side effects which will require you to force the entire tree to update 19

21 Partial Refresh (cont.) If you want the server to always render the whole view tree you can: Add xsp.ajax.renderwholetree=true to the xsp.properties This file is in the WebContent/WEB-INF/ directory Use Partial Refresh where ever possible so only that portion of the JSF tree is processed and not the entire component tree 20

22 The DataCache Property Used for caching Domino view data Persisted view data consumes JVM memory Use if the view data isn t needed in a POST request Three values are supported for the DataCache property: Full [default] ID The entire view is persisted Minimal scalar data ID and position. Access to column values during a POST are not available. None Enough said the entire view needs to be reconstructed 21

23 Partial Execution Controls how much component tree processing happens during phases 2-5 of the JSF lifecycle Partial Execution is purely a server-side optimization Partial Refresh and Partial Execution are mutually exclusive and do not depend on each other in any way 22

24 Partial Execution (cont.) Set the execmode property on server events using: Set partial execution mode in the Server Settings section The default is complete and when checked is set to partial Very powerful when used inside of a View Panel, Data Table, or Repeat Control Child controls can have this property set which will not cause the parent control to not be re-executed during invocation of a child event handler Did I mention that this is very powerful and you should carefully review your code to ensure that you are taking advantage of Partial Execution wherever possible? 23

25 Exploring the XPages Request Processing Lifecycle So how do you know when and where your code is executing in the JSF Lifecycle? Couple this with Partial Refresh and Partial Execution of controls and things can become pretty complex exponentially. IBM s Tony McGuckin has posted code on the OpenNTF Xsnippets site that will help you learn more about the JSF lifecycle. It will also clearly show you which phase(s) of the lifecycle your code is being executed. A sample XPage is included. id=xpages-request-processing-lifecycle-explorercode... 24

26 The Sample XPage The sample XPage that we are going to examine has: The XPage view has the following event handlers defined: beforepageload afterpageload afterrestoreview beforerenderresponse afterrenderresponse Each of these events has a print statement that will print out to the Domino console Let s look at the page design and them walk through some of examples 25

27 Sample Lifecycle XPage Layout Domino Designer Design View 26

28 Sample Lifecycle XPage Layout (cont.) Web browser view 27

29 LifeCycle.nsf Page Initial Load Output All of the controls are rendered and then JSF Phase 6 28

30 P2 Button Clicked Output Button P2 s onclick event is set to Partial Refresh of the P2 panel Partial Execution Mode has also been selected with an execid of P2 29

31 P2 Immediate Button Clicked Output Button P2 s click event is set to Partial Refresh of the P2 panel Partial Execution Mode has also been selected and set to execid P2 The immediate property of the button s onclick event has been set which will bypass any validation Typically used to save a document in draft form 30

32 P2 Button Disable Validators Clicked Button P2 s click event is set to Partial Refresh of the P2 panel Partial Execution Mode has also been selected and set to execid P2 The Process data without validation checkbox is enabled (disablevalidators= true ). All phases are executed. 31

33 P1 Button Clicked Button P1 s click event is set to Partial Refresh of the P1 panel Partial Execution Mode has also been selected and set to execid P1 Pretty much what we expected 32

34 P1 Button Immediate Clicked Button P1 s click event is set to Partial Refresh of the P1 panel Partial Execution Mode has also been selected and set to execid P1 The immediate property of the button s onclick event has been set which will bypass any validation 33

35 P1 Button Disable Validators Clicked Button P1 s click event is set to Partial Refresh of the P1 panel Partial Execution Mode has also been selected and set to execid P1 The Process data without validation checkbox is enabled (disablevalidators= true ). All phases are executed. 34

36 P2 No ID Partial Execute/Full Refresh 05/10/ :46:14 AM HTTP JVM: Request: Started... 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: Lifecycle: Before Phase: RESTORE_VIEW 1 05/10/ :46:14 AM HTTP JVM: Page: view1->afterrestoreview 05/10/ :46:14 AM HTTP JVM: Lifecycle: After Phase: RESTORE_VIEW 1 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: Lifecycle: Before Phase: APPLY_REQUEST_VALUES 2 05/10/ :46:14 AM HTTP JVM: Control: txt2->rendered 05/10/ :46:14 AM HTTP JVM: Lifecycle: After Phase: APPLY_REQUEST_VALUES 2 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: Lifecycle: Before Phase: PROCESS_VALIDATIONS 3 05/10/ :46:14 AM HTTP JVM: Control: txt2->rendered 05/10/ :46:14 AM HTTP JVM: Lifecycle: After Phase: PROCESS_VALIDATIONS 3 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: Lifecycle: Before Phase: UPDATE_MODEL_VALUES 4 05/10/ :46:14 AM HTTP JVM: Control: txt2->rendered 05/10/ :46:14 AM HTTP JVM: Lifecycle: After Phase: UPDATE_MODEL_VALUES 4 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: Lifecycle: Before Phase: INVOKE_APPLICATION 5 05/10/ :46:14 AM HTTP JVM: Lifecycle: After Phase: INVOKE_APPLICATION 5 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: Lifecycle: Before Phase: RENDER_RESPONSE 6 05/10/ :46:14 AM HTTP JVM: Page: view1->beforerenderresponse 05/10/ :46:14 AM HTTP JVM: Control: txt1->rendered 05/10/ :46:14 AM HTTP JVM: Control: txt2->rendered 05/10/ :46:14 AM HTTP JVM: Control: txt3->rendered 05/10/ :46:14 AM HTTP JVM: Page: view1->afterrenderresponse 05/10/ :46:14 AM HTTP JVM: Lifecycle: After Phase: RENDER_RESPONSE 6 05/10/ :46:14 AM HTTP JVM: 05/10/ :46:14 AM HTTP JVM: Request: Completed. 35

37 P2 Full Execute/Partial Refresh 05/10/ :49:31 AM HTTP JVM: Request: Started... 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: Lifecycle: Before Phase: RESTORE_VIEW 1 05/10/ :49:31 AM HTTP JVM: Page: view1->afterrestoreview 05/10/ :49:31 AM HTTP JVM: Lifecycle: After Phase: RESTORE_VIEW 1 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: Lifecycle: Before Phase: APPLY_REQUEST_VALUES 2 05/10/ :49:31 AM HTTP JVM: Control: txt1->rendered 05/10/ :49:31 AM HTTP JVM: Control: txt2->rendered 05/10/ :49:31 AM HTTP JVM: Control: txt3->rendered 05/10/ :49:31 AM HTTP JVM: Lifecycle: After Phase: APPLY_REQUEST_VALUES 2 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: Lifecycle: Before Phase: PROCESS_VALIDATIONS 3 05/10/ :49:31 AM HTTP JVM: Control: txt1->rendered 05/10/ :49:31 AM HTTP JVM: Control: txt2->rendered 05/10/ :49:31 AM HTTP JVM: Control: txt3->rendered 05/10/ :49:31 AM HTTP JVM: Lifecycle: After Phase: PROCESS_VALIDATIONS 3 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: Lifecycle: Before Phase: UPDATE_MODEL_VALUES 4 05/10/ :49:31 AM HTTP JVM: Control: txt1->rendered 05/10/ :49:31 AM HTTP JVM: Control: txt2->rendered 05/10/ :49:31 AM HTTP JVM: Control: txt3->rendered 05/10/ :49:31 AM HTTP JVM: Lifecycle: After Phase: UPDATE_MODEL_VALUES 4 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: Lifecycle: Before Phase: INVOKE_APPLICATION 5 05/10/ :49:31 AM HTTP JVM: Event: p2->partial refresh value: /10/ :49:31 AM HTTP JVM: Lifecycle: After Phase: INVOKE_APPLICATION 5 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: Lifecycle: Before Phase: RENDER_RESPONSE 6 05/10/ :49:31 AM HTTP JVM: Page: view1->beforerenderresponse 05/10/ :49:31 AM HTTP JVM: Control: txt2->rendered 05/10/ :49:31 AM HTTP JVM: Page: view1->afterrenderresponse 05/10/ :49:31 AM HTTP JVM: Lifecycle: After Phase: RENDER_RESPONSE 6 05/10/ :49:31 AM HTTP JVM: 05/10/ :49:31 AM HTTP JVM: Request: Completed. 36

38 P2 Partial Execute/Partial Refresh 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Request: Started... 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Lifecycle: Before Phase: RESTORE_VIEW 1 05/10/ :50:53 AM HTTP JVM: Page: view1->afterrestoreview 05/10/ :50:53 AM HTTP JVM: Lifecycle: After Phase: RESTORE_VIEW 1 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Lifecycle: Before Phase: APPLY_REQUEST_VALUES 2 05/10/ :50:53 AM HTTP JVM: Control: txt2->rendered 05/10/ :50:53 AM HTTP JVM: Lifecycle: After Phase: APPLY_REQUEST_VALUES 2 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Lifecycle: Before Phase: PROCESS_VALIDATIONS 3 05/10/ :50:53 AM HTTP JVM: Control: txt2->rendered 05/10/ :50:53 AM HTTP JVM: Lifecycle: After Phase: PROCESS_VALIDATIONS 3 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Lifecycle: Before Phase: UPDATE_MODEL_VALUES 4 05/10/ :50:53 AM HTTP JVM: Control: txt2->rendered 05/10/ :50:53 AM HTTP JVM: Lifecycle: After Phase: UPDATE_MODEL_VALUES 4 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Lifecycle: Before Phase: INVOKE_APPLICATION 5 05/10/ :50:53 AM HTTP JVM: Lifecycle: After Phase: INVOKE_APPLICATION 5 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Lifecycle: Before Phase: RENDER_RESPONSE 6 05/10/ :50:53 AM HTTP JVM: Page: view1->beforerenderresponse 05/10/ :50:53 AM HTTP JVM: Control: txt2->rendered 05/10/ :50:53 AM HTTP JVM: Page: view1->afterrenderresponse 05/10/ :50:53 AM HTTP JVM: Lifecycle: After Phase: RENDER_RESPONSE 6 05/10/ :50:53 AM HTTP JVM: 05/10/ :50:53 AM HTTP JVM: Request: Completed. 05/10/ :50:53 AM HTTP JVM: 37

39 P1 No ID Partial Execute/Full Refresh 05/10/ :55:07 AM HTTP JVM: Request: Started... 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: Lifecycle: Before Phase: RESTORE_VIEW 1 05/10/ :55:07 AM HTTP JVM: Page: view1->afterrestoreview 05/10/ :55:07 AM HTTP JVM: Lifecycle: After Phase: RESTORE_VIEW 1 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: Lifecycle: Before Phase: APPLY_REQUEST_VALUES 2 05/10/ :55:07 AM HTTP JVM: Lifecycle: After Phase: APPLY_REQUEST_VALUES 2 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: Lifecycle: Before Phase: PROCESS_VALIDATIONS 3 05/10/ :55:07 AM HTTP JVM: Lifecycle: After Phase: PROCESS_VALIDATIONS 3 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: Lifecycle: Before Phase: UPDATE_MODEL_VALUES 4 05/10/ :55:07 AM HTTP JVM: Lifecycle: After Phase: UPDATE_MODEL_VALUES 4 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: Lifecycle: Before Phase: INVOKE_APPLICATION 5 05/10/ :55:07 AM HTTP JVM: Event: no id->partial execute value: /10/ :55:07 AM HTTP JVM: Lifecycle: After Phase: INVOKE_APPLICATION 5 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: Lifecycle: Before Phase: RENDER_RESPONSE 6 05/10/ :55:07 AM HTTP JVM: Page: view1->beforerenderresponse 05/10/ :55:07 AM HTTP JVM: Control: txt1->rendered 05/10/ :55:07 AM HTTP JVM: Control: txt2->rendered 05/10/ :55:07 AM HTTP JVM: Control: txt3->rendered 05/10/ :55:07 AM HTTP JVM: Page: view1->afterrenderresponse 05/10/ :55:07 AM HTTP JVM: Lifecycle: After Phase: RENDER_RESPONSE 6 05/10/ :55:07 AM HTTP JVM: 05/10/ :55:07 AM HTTP JVM: Request: Completed. 38

40 P1 No ID Full Execute/Partial Refresh 05/10/ :56:40 AM HTTP JVM: Request: Started... 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: Lifecycle: Before Phase: RESTORE_VIEW 1 05/10/ :56:40 AM HTTP JVM: Page: view1->afterrestoreview 05/10/ :56:40 AM HTTP JVM: Lifecycle: After Phase: RESTORE_VIEW 1 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: Lifecycle: Before Phase: APPLY_REQUEST_VALUES 2 05/10/ :56:40 AM HTTP JVM: Control: txt1->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt2->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt3->rendered 05/10/ :56:40 AM HTTP JVM: Lifecycle: After Phase: APPLY_REQUEST_VALUES 2 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: Lifecycle: Before Phase: PROCESS_VALIDATIONS 3 05/10/ :56:40 AM HTTP JVM: Control: txt1->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt2->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt3->rendered 05/10/ :56:40 AM HTTP JVM: Lifecycle: After Phase: PROCESS_VALIDATIONS 3 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: Lifecycle: Before Phase: UPDATE_MODEL_VALUES 4 05/10/ :56:40 AM HTTP JVM: Control: txt1->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt2->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt3->rendered 05/10/ :56:40 AM HTTP JVM: Lifecycle: After Phase: UPDATE_MODEL_VALUES 4 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: Lifecycle: Before Phase: INVOKE_APPLICATION 5 05/10/ :56:40 AM HTTP JVM: Event: no id->partial refresh value: /10/ :56:40 AM HTTP JVM: Lifecycle: After Phase: INVOKE_APPLICATION 5 39

41 P1 No ID Full Execute/Partial Refresh (cont.) 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: Lifecycle: Before Phase: RENDER_RESPONSE 6 05/10/ :56:40 AM HTTP JVM: Page: view1->beforerenderresponse 05/10/ :56:40 AM HTTP JVM: Control: txt1->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt2->rendered 05/10/ :56:40 AM HTTP JVM: Control: txt3->rendered 05/10/ :56:40 AM HTTP JVM: Page: view1->afterrenderresponse 05/10/ :56:40 AM HTTP JVM: Lifecycle: After Phase: RENDER_RESPONSE 6 05/10/ :56:40 AM HTTP JVM: 05/10/ :56:40 AM HTTP JVM: Request: Completed. 40

42 P1 No ID Partial Execute/Partial Refresh 05/10/ :00:19 AM Finished replication with server NA1/ideaExchange 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: Request: Started... 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: Lifecycle: Before Phase: RESTORE_VIEW 1 05/10/ :00:21 AM HTTP JVM: Page: view1->afterrestoreview 05/10/ :00:21 AM HTTP JVM: Lifecycle: After Phase: RESTORE_VIEW 1 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: Lifecycle: Before Phase: APPLY_REQUEST_VALUES 2 05/10/ :00:21 AM HTTP JVM: Lifecycle: After Phase: APPLY_REQUEST_VALUES 2 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: Lifecycle: Before Phase: PROCESS_VALIDATIONS 3 05/10/ :00:21 AM HTTP JVM: Lifecycle: After Phase: PROCESS_VALIDATIONS 3 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: Lifecycle: Before Phase: UPDATE_MODEL_VALUES 4 05/10/ :00:21 AM HTTP JVM: Lifecycle: After Phase: UPDATE_MODEL_VALUES 4 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:21 AM HTTP JVM: Lifecycle: Before Phase: INVOKE_APPLICATION 5 05/10/ :00:21 AM HTTP JVM: Event: no id->partial refresh/execute value: /10/ :00:21 AM HTTP JVM: Lifecycle: After Phase: INVOKE_APPLICATION 5 05/10/ :00:21 AM HTTP JVM: 05/10/ :00:22 AM HTTP JVM: 05/10/ :00:22 AM HTTP JVM: Lifecycle: Before Phase: RENDER_RESPONSE 6 05/10/ :00:22 AM HTTP JVM: Page: view1->beforerenderresponse 05/10/ :00:22 AM HTTP JVM: Control: txt1->rendered 05/10/ :00:22 AM HTTP JVM: Control: txt2->rendered 05/10/ :00:22 AM HTTP JVM: Control: txt3->rendered 05/10/ :00:22 AM HTTP JVM: Page: view1->afterrenderresponse 05/10/ :00:22 AM HTTP JVM: Lifecycle: After Phase: RENDER_RESPONSE 6 05/10/ :00:22 AM HTTP JVM: 05/10/ :00:22 AM HTTP JVM: Request: Completed. 41

43 New in Domino Use runtime optimized JavaScript and CSS resources 42

44 New in Domino (cont.) Before and after 43

45 New in Domino (cont.) Pre-load XPage engine to improve startup times XPagesPreload=1 in notes.ini You can now pre-load XPages Java code into memory This makes your apps more responsive on first use In your notes.ini file you can specify which databases to pre-load: XPagesPreloadDB=servername!!path/mydb.nsf/ myxpage.xsp,servername!!path/anotherdb.nsf 44

46 Single Copy XPage Design (SCXD) New with Domino www-10.lotus.com/ldd/ddwiki.nsf/dx/single_copy_xpage_design 45

47 Single Copy XPage Design (SCXD) (cont.) Allows lots of applications using the same template to share XPage code Saves loading more XPages into server memory Good example is the Discussion template Another example is from XPages developer Declan Lynch who has 96,000 databases which share the same design thus saving approximately 6mb per database (that s 562gb!) You will need to restart HTTP in order for new design changes to be picked up by databases relying on your SCXD database A note on SCXD (Single Copy XPage Design), IBM fixed a high severity bug (PHAN8N3HZ9) where the SCXD would timeout causing an exception under a certain scenario. This fix will be available in FP1. A Hot fix is also available. 46

48 Quick Performance Hits Give the server lots and lots and lots of RAM. And then some more. Rinse and repeat. Use a 64-bit OS whenever possible Devote fast disk or SSD to your servers program files volume This is where the XPages code is called from Isolate heavily used XPages apps, especially from other memory intensive apps such as Traveler Consider dedicated Domino instances for large applications 47

49 Setting the Data Scope for a View When you add data sources to your XPage, each one has a scope It s set under All Properties in the XPage Data, name, scope The default is viewscope Data is stored as part of the page If you want to cut down on as much memory usage as possible, and you are not relying on pass through parameters like a filter or a search Set the value of scope to request 48

50 Let s Get Synchronized Every bit of performance we can gain is a good thing for the person using our XPages applications Many applications have several commonly used pieces of code that get executed over and over again An example would be an application that has a control panel type of interface This interface allows you to configure and enable/disable features and functions in the application Having your application constantly calling the same code over and over again is not efficient There is a better way to handle these types of situations Synchronize to the rescue 49

51 Let s Get Synchronized (cont.) Java has a synchronized keyword This keyword is now available for you to use in your Server- Side JavaScript code What does it do? It prevents the same code block from running concurrently when being called by multiple areas of the system Subsequent calls get queued up and are executed one after another The results can then be cached The queued up calls can get the result from memory (applicationscope for example) No need to recalculate over and over again Let s look at some code 50

52 Let s Get Synchronized (cont.) function getcontrolpanelfieldstring(fieldname) { synchronized(applicationscope) { if (iscacheinvalid("controlpanel_" + fieldname, 600)) { var controlpanels = database.getview("lookupcontrolpanel"); } var controlpanel = controlpanels.getfirstdocument(); applicationscope.put("controlpanel_" + fieldname, controlpanel.getitemvaluestring(fieldname)); controlpanel = null; controlpanels = null; } } return applicationscope.get("controlpanel_" + fieldname); Code walkthrough Note that the code block is wrapped by synchronized{} A call to the iscachedinvalid function is made to see if the variable we need is still in the cache and is still valid based on the second parameter which is the time in seconds If the time period has expired we then perform the calculation and place in the applicationscope 51

53 Let s Get Synchronized (cont.) /*A generic caching mechanism for each key will check to see if it is 'n' seconds since it was last updated. Use this for things that change relatively infrequently */ function iscacheinvalid(key, cacheinterval) { var currenttime = new Date().getTime(); if (!applicationscope.containskey(key + "_time")) { applicationscope.put(key + "_time", currenttime); return true; } var diffinsecs = Math.ceil((currentTime - applicationscope.get(key + "_time")) / 1000); } if (diffinsecs < cacheinterval) { return false; } else { } applicationscope.put(key + "_time", currenttime); return true; Code walkthrough (cont.) The iscacheinvalid function simply checks to see if the time has expired (cacheinterval) It returns false if it has not expired and true if it has 52

54 Controlling the Memory Size of the JVM on the Server There are two notes.ini settings on the server that are important HTTPJVMMaxHeapSize HTTPJVMMaxHeapSizeSet The HTTPJVMMaxHeapSize parameter Specifies the maximum memory allocated to the JVM Recommended that you set to 512M or 1024M on a production server. ¼ of total RAM is a good rule of thumb. The HTTPJVMMaxHeapSizeSet parameter Ensure that HTTPJVMMaxHeapSizeSet is set to 1 to ensure that the server does not reset to 64M during a restart or upgrade 53

55 Application Properties In Domino Designer each database has an Application Properties panel There are now several panels specifically for XPages settings New in 8.5.3! Package Explore > WebContent > WEB-INF > xsp.properties These values are stored in a properties file located in the xsp.persistence.* Properties basic: Keeps all pages in memory (performs well) limited to four pages file: Keep all files on disk fileex: Keeps only the current page in memory (scales and performs well) 54

56 XPage Application Properties 55

57 View Design Considerations Carefully review the structure and settings of your views The same rules apply for using views within XPages Well-performing and tuned views are critical well-performing XPage applications Some golden rules for views Limit the number of sorted columns Unnecessary columns Overly complex in formulas 56

58 What We ll Cover Things to consider when moving applications to XPages Understanding the JSF lifecycle and how it relates to XPages application design Development best practices for performance and scalability How to identify application bottlenecks using the OpenNTF XPages Toolbox Third-party tools to help profile your applications performance Wrap-up 57

59 The OpenNTF XPages Toolbox The XPages toolbox proposes a set of tools useful to the XPages developer, including a full fledged CPU profiler and memory profiler. Moreover, it is based on an extensible architecture aimed to host other services for developers. Available as an open source project on OpenNTF ProjectLookup/XPages%20Toolbox 58

60 What You Will Learn About the XPages Toolbox What exactly you can do with the toolbox How to install it on your Domino server Verify that it is installed correctly and running Take a quick tour of the XPages Toolbox application from a Web browser Learn how to identify problem areas in your code using the CPU and Wall timers Learn how to profile sections of your code using profile(){} code blocks 59

61 What You Can Do with the XPages Toolbox The XPages Toolbox has five key features: 1. The CPU profiler 2. The back-end classes profiler 3. The memory profiler 4. Runtime monitoring 5. Java logging groups management 60

62 The CPU Profiler The CPU profiler is a high-level profiler recording the XPages activity and gathering the time spent in the different parts of the XPages (JSF lifecycle, JavaScript code, and custom code) 61

63 CPU Time and Wall Time CPU time The time actually spent by the CPU executing code Wall time The real-world time elapsed between method entry and method exit If there are other threads/processes concurrently running on the system, they can affect the results 62

64 The Back-End Classes Profiler This module gathers, per request, how the back-end classes are being called and the time spent in each call Note that it only measures the Wall time When enabled, one document is created per XPages request Each document contains the information within a rich text field 63

65 The Memory Profiler Used to show the memory being used by the XPages runtime The data is presented categorized by application (NSFs) and opened sessions 64

66 Runtime Monitoring Used to grab a high-level view of the memory being used by the JVM Also records the number of active modules (NSFs) and sessions 65

67 Java Logging Groups Management XPages takes advantage of the Java Logging API to trace what is happening in the runtime The logging levels are initially defined in a file located within the jvm directory:<domino>/jvm/lib/logging.properties The toolbox allows you to dynamically see what are the enabled groups and change their level on the fly, without having to restart the JVM 66

68 Installing the XPages Toolbox on Your Server The XPages Toolbox requires Domino Server V8.5.2 or greater An Important Security Warning The memory profiler can display and store files on the server that contain information coming from some live XPages sessions Do not install on a production server Remove the toolbox NSF as soon as you re done with it Protecting its access using ACLs Requires a modification to the servers java.policy to explicitly enable the XPages Toolbox application 67

69 What s in the XPages Toolbox Download File? com.ibm.commons.profileragent.zip The Java source code of the profiler agent java.policy Contains the policy update that you will need to make LICENSE The Apache license file NOTICE Part of the Apache license Screenshots folder Some screenshots of the XPages Toolbox 68

70 What s in the XPages Toolbox Download File? (cont.) XPagesProfilerAgent.jar The Java jar file that contains the core XPages Toolbox monitoring code XPagesToolbox.nsf The Notes database that you will access from the Web to profile your XPages applications XPagesToolbox.odt The Lotus Symphony file containing the documentation XspProfilerOptionsFile.txt A file that contains information that is needed by the profiler agent This file will be referenced in a notes.ini setting 69

71 Installing the Java Profiler Agent The java agent is provided as a jar file (XPagesProfilerAgent.jar) that must be copied to the <domino>/xsp directory Copy the XspProfilerOptionsFile.txt file to your domino main directory Insert the following lines into notes.ini (assuming that domino is installed in c:\domino) ; XPages Profiler JavaOptionsFile=c:\Domino\XspProfilerOptionsFile.txt If the agent is correctly installed, the Domino console should display the following message when the http task is started 70

72 Updating the Java Policy File The java policy file is located in the <domino>/jvm/lib/security directory Assuming that the NSF is not installed in a sub-directory, the following lines should be added at the end of the java.policy file grant codebase "xspnsf://server:0/xpagestoolbox.nsf/ script/-" { permission com.ibm.designer.runtime.domino.adapter.security.adminper mission "AdminPermission.debug";}; Be sure and save the java.policy file! 71

73 Installing the XPagesToolbox.nsf Database Copy the XPagesToolbox.nsf database file to the Domino server Be sure and install it in the location specified in the Installing the Java Profiler Agent step Set the database ACL Don t forget about the security warnings we mentioned! Sign the database with the appropriate ID You may need to work with your Domino Administrator on this Access the XPagesToolbox.nsf from a browser Congratulations! You are ready to start profiling 72

74 Installing the XPagesToolbox.nsf Database (cont.) If the database was installed correctly you should see this screen 73

75 Profiling Your XPages Code with the CPU Profiler Let s profile a code block from an XPages application We will profile it using the Wall Timer First we will profile a Server-Side JavaScript function as is Then we will add some code into the function to cause it to be less efficient It s going to feel sleepy the code that is You will clearly be able to see how the CPU Profiler will become your new best friend 74

76 The JavaScript Function We Will Profile Looks like perfectly innocent code right? Well it actually is: 75

77 Let s Profile the Function Start the Wall timer by clicking the Start Wall Time Profiler from the XPages Toolbox CPU Profiler tab Access the Web page that uses the getimagehtml function Now stop the Wall timer by clicking the Stop Profiler button Take note of the getimagehtml function and the Specific Time Didn t take more than a fraction of a second to complete 76

78 Now Let s Make Our Sample JavaScript Function Sleepy We have added a simple sleep statement to our JavaScript function 77

79 Re-Running the CPU Profiler on the Sleepy Code Notice that the operation now took over 5 seconds 78

80 Profiling Specific Code Blocks The XPages runtime currently monitors some well known operations, the JSF phases and data access Developers can also monitor their own code blocks in either Java or JavaScript Each block is defined by a type (a string constant) and an optional content The content is used to categorize different instances of the same type. For example, the type can be JavaScript expression and the content is the JavaScript code itself. Let s look at how to monitor code blocks in JavaScript 79

81 Using the profile Keyword to Monitor Code Blocks The XPages server-side JavaScript interpreter has an extra keyword in the runtime that defines a block of code to monitor profile(<type>[,content]) {... } Here is an example monitoring a custom block of code in our getinnerhtml JavaScript function from the previous slides profile("developer 2011","myBlock1") { java.lang.thread.sleep(1000); } 80

82 Viewing the Profile Data for Profiled Blocks You can see in the screen below that Developer 2011 has been profiled and is shown under the myblock1 Content identifier that we gave it 81

83 Let s Look at the Back-End Class Profiler Remember that when the Back-End Class Profiler is run it s going to create a single document for the entire page load To start the profiling process click on the Start Profiler button To stop the profiling process click on the Stop Profiler button Now opening up a contact record in my XPages app generated this document 82

84 Let s Look at the Back-End Class Profiler (cont.) Here is the document that was generated Note the class names and methods that were called Note the type of operation (GET/POST) The number of calls and the time they took 83

85 Let s Look at the Runtime Monitoring Screen Remember that Runtime Monitoring? Shows the number of running modules (NSFs) The number of active sessions It will also show you: The total memory used by the modules The amount of free memory available in the JVM The total memory allocated for the JVM 84

86 Let s Look at the Runtime Monitoring Screen (cont.) You can take an initial snapshot of the runtime by clicking the Take Snapshot button To start monitoring click the Start Monitoring button To stop monitoring click the Stop Monitoring button You can also specify how often a snapshot will be taken 85

87 Looking at the Memory Inspector Tab Using the Memory Inspector is something reserved for those who really want to dig into the inner workings of Java The Memory Inspector generates XML files that are stored on the Domino server when the Dump Sessions button is clicked 86

88 Java Logging Groups Management This screen simply allows you to refine the level of logging for any of the runtime and back-end classes Change the logging level for each item as you deem necessary to help you in your XPages performance tuning 87

89 What We ll Cover Things to consider when moving applications to XPages Understanding the JSF lifecycle and how it relates to XPages application design Development best practices for performance and scalability How to identify application bottlenecks using the OpenNTF XPages Toolbox Third-party tools to help profile your applications performance Wrap-up 88

90 Third-Party Client-Side Tools There are many third-party tools that you can use to help profile and analyze your application Most of these tools are browser plug-ins Some are online services These tools will analyze the Web pages generated by your XPages applications and Make recommendations on what elements of the page you can improve upon Allow you to see exactly what the browser is seeing and how your code is being loaded, executed, and rendered You should test your applications on different browsers The recommendations made by these tools are pretty much Web browser agnostic 89

91 The Tools We Will Be Looking At Firefox Plugins YSlow Page Speed Safari and Chrome Extensions Web Inspector (WebKit) Internet Explorer 6, 7, and 8 dynatrace AJAX Edition 90

92 The Tools We Will Be Looking At (cont.) Online testing site WebPageTest.org Other considerations There are still many organizations using IE6 believe it or not If you are a commercial developer you may find that you have to support it 91

93 YSlow Firefox Plugin YSlow Developed by Yahoo! Assigns and overall grade to a Web page Shows grades for things such as: Putting CSS in the page head Avoid URL redirects Compress components with GZIP Use GET for AJAX requests Do not scale images in HTML And many others 92

94 YSlow Firefox Plugin (cont.) Running YSlow on the Elguji.com site Note the various grades assigned Overall grade of A Note other grades 93

95 Page Speed Firefox Plugin Running Page Speed on the IQJam.net site Overall grade of 89/100 You can expand each section for more detailed information Note similar results to YSlow 94

96 WebPageTest.org A site where you enter the URL for your site and have it tested Won t work for internal sites 95

97 Web Inspector Firefox and Chrome Monitor elements when they are: Loading Scripting Rendering The Web Inspector in Chrome also has a nice audit feature Not as feature complete as YSlow and Page Speed 96

98 dynatrace AJAX Edition Internet Explorer Provides an overall performance report for a site in the form of a grade Identifies potential hotspots that should be looked into 97

99 What We ll Cover Things to consider when moving applications to XPages Understanding the JSF lifecycle and how it relates to XPages application design Development best practices for performance and scalability How to identify application bottlenecks using the OpenNTF XPages Toolbox Third-party tools to help profile your applications performance Wrap-up 98

100 Additional Resources OpenNFT Open source community for Lotus Notes and Domino XPages.info A great starting point for learning XPages XPages.info Blog A blog covering all things on on Twitter 99

101 7 Key Points to Take Home Know when and where to employ XPages when developing your applications The hybrid development approach (XPages and classic Notes/ Domino development) is extremely popular and low risk Unlike developing classic Domino applications, developing XPages applications requires that you understand the 6 phase JSF Lifecycle Learn as much you can about the various options that are available for each of the core controls as they can impact the performance of your XPage Know how to use the XPages Toolbox profiler Become familiar with and start to use the third-party tools to profile your shiny new XPages application from the Web browser Compress (when you can) CSS, JavaScript, and images 100

102 Your Turn! How to contact me: Bruce Elgort 101