{"id":572,"date":"2012-02-20T12:51:13","date_gmt":"2012-02-20T10:51:13","guid":{"rendered":"http:\/\/hasselba.ch\/blog\/?p=572"},"modified":"2012-02-20T12:58:54","modified_gmt":"2012-02-20T10:58:54","slug":"performance-killer-in-der-xpage","status":"publish","type":"post","link":"https:\/\/hasselba.ch\/blog\/?p=572","title":{"rendered":"Performance-Killer in der XPage"},"content":{"rendered":"

Dank einer Frage von Ulrich Krause im XPages Developer Forum<\/a> wurde ein Thema „wiederbelebt“, das mir vor einiger Zeit in einem Projekt aufgefallen ist und sich als wahre Bremse bei XPages-Applikationen herausstellt:<\/p>\n

S\u00e4mtliche Datenquellen (DataContext-Variablen, Repeat Controls, usw.) werden bei jedem<\/span> Partial Refresh neu berechnet, auch wenn sie nicht das Ziel (bzw. ein Kind-Element des Ziels) des Refreshs sind.<\/p>\n

Ich nutze als Beispiel hierf\u00fcr die von Ulrich Krause gepostete Beispiel-XPage<\/a>, um das Problem zu verdeutlichen. Den fett markierten Code ist von mir zur Verdeutlichung auf der Serverkonsole eingebaut worden, dass es sich nicht um einen fehlerhaftes print-Statement handelt, sondern der Code wirklich neu berechnet wird.<\/p>\n

<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<xp:view xmlns:xp=\"http:\/\/www.ibm.com\/xsp\/core\">\r\n <xp:button value=\"Label\" id=\"button1\">\r\n <xp:eventHandler event=\"onclick\" submit=\"true\"\r\n refreshMode=\"partial\" refreshId=\"col1\" \/>\r\n <\/xp:button>\r\n <xp:table>\r\n <xp:tr>\r\n <xp:td id=\"col1\">\r\n <xp:text escape=\"true\" id=\"computedField2\"\r\n   value=\"#{javascript:@Now()}\">\r\n <xp:this.converter>\r\n <xp:convertDateTime type=\"both\" \/>\r\n <\/xp:this.converter>\r\n <\/xp:text>\r\n <\/xp:td>\r\n <xp:td id=\"col2\">\r\n <xp:text escape=\"true\" id=\"computedField1\"\r\n   value=\"#{javascript:@Now()}\">\r\n <xp:this.converter>\r\n <xp:convertDateTime type=\"both\" \/>\r\n <\/xp:this.converter>\r\n <\/xp:text>\r\n <xp:dataTable id=\"dataTable1\" rows=\"30\">\r\n <xp:this.value><![CDATA[#{javascript:\r\n print(java.lang.System.currentTimeMillis()<\/strong> + ' You shall not refresh');\r\n}]]><\/xp:this.value>\r\n <xp:column id=\"column1\" \/>\r\n <\/xp:dataTable>\r\n <\/xp:td>\r\n <\/xp:tr>\r\n <\/xp:table>\r\n<\/xp:view><\/pre>\n
Wird der Button geklickt, wird ein Refresh auf das Element mit der Id „col1“ ausgel\u00f6st, und eigentlich d\u00fcrfte die Data Table nicht neu berechnet werden, doch genau das ist aber der Fall!<\/p>\n
[Die Ausgabe auf der Serverkonsole habe ich mit einem Debug PhaseListener kombiniert, um die Phasen im Lifecycle hervorzuheben]<\/em><\/p>\n
Button<\/h2>\n
<xp:button value=\"Label\" id=\"button1\">\r\n   <xp:eventHandler event=\"onclick\" submit=\"true\"\r\n      refreshMode=\"partial\" refreshId=\"col1\" \/>\r\n<\/xp:button><\/pre>\n
1. \u00d6ffnen der XPage<\/h2>\n
19.02.2012 18:02:17\u00a0 \u00a0HTTP JVM: Before phase: RENDER_RESPONSE 6\r\n19.02.2012 18:02:17\u00a0 \u00a0HTTP JVM: 1329670937472 You shall not refresh<\/strong>\r\n19.02.2012 18:02:17\u00a0 \u00a0HTTP JVM: After phase: RENDER_RESPONSE 6<\/pre>\n
2. Partial Refresh<\/h2>\n
19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: Before phase: RESTORE_VIEW 1\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: After phase: RESTORE_VIEW 1\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: Before phase: APPLY_REQUEST_VALUES 2\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: 1329671137733 You shall not refresh<\/strong>\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: After phase: APPLY_REQUEST_VALUES 2\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: Before phase: PROCESS_VALIDATIONS 3\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: After phase: PROCESS_VALIDATIONS 3\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: Before phase: UPDATE_MODEL_VALUES 4\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: After phase: UPDATE_MODEL_VALUES 4\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: Before phase: INVOKE_APPLICATION 5\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: After phase: INVOKE_APPLICATION 5\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: Before phase: RENDER_RESPONSE 6\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: 1329671137769 You shall not refresh<\/strong>\r\n19.02.2012 18:05:37\u00a0 \u00a0HTTP JVM: After phase: RENDER_RESPONSE 6<\/pre>\n
Die Berechung der DataTable erfolgt zwei Mal w\u00e4hren des Partial Refreshs.<\/p>\n
\u00c4ndert man die Ausf\u00fchrung des Buttons auf Partial Excecution, erh\u00e4lt man folgendes Ergebnis:<\/p>\n
Button<\/h2>\n
<xp:button value=\"Label\" id=\"button1\" execMode=\"partial\">\r\n   <xp:eventHandler event=\"onclick\" submit=\"true\"\r\n   refreshMode=\"partial\" refreshId=\"col1\" \/>\r\n<\/xp:button><\/pre>\n
1. \u00d6ffnen der XPage<\/h2>\n
19.02.2012 18:13:54\u00a0 \u00a0HTTP JVM: Before phase: RENDER_RESPONSE 6\r\n19.02.2012 18:13:54\u00a0 \u00a0HTTP JVM: 1329671634490 You shall not refresh<\/strong>\r\n19.02.2012 18:13:54\u00a0 \u00a0HTTP JVM: After phase: RENDER_RESPONSE 6<\/pre>\n
2. Partial Refresh<\/h2>\n
19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: Before phase: RESTORE_VIEW 1\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: After phase: RESTORE_VIEW 1\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: Before phase: APPLY_REQUEST_VALUES 2\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: 1329671642321 You shall not refresh<\/strong>\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: After phase: APPLY_REQUEST_VALUES 2\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: Before phase: PROCESS_VALIDATIONS 3\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: After phase: PROCESS_VALIDATIONS 3\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: Before phase: UPDATE_MODEL_VALUES 4\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: After phase: UPDATE_MODEL_VALUES 4\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: Before phase: INVOKE_APPLICATION 5\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: After phase: INVOKE_APPLICATION 5\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: Before phase: RENDER_RESPONSE 6\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: 1329671642360 You shall not refresh<\/strong>\r\n19.02.2012 18:14:02\u00a0 \u00a0HTTP JVM: After phase: RENDER_RESPONSE 6<\/pre>\n
Wieder erfolgt die Berechung der DataTable zwei Mal w\u00e4hren des Partial Refreshs.<\/p>\n
Eine \u00c4nderung des Execution-Modes des Events verringert die Berechnung zumindest auf eine Neuberechnung pro Partial Refresh:<\/p>\n
Button<\/h2>\n
<xp:button value=\"Label\" id=\"button1\" execMode=\"partial\">\r\n\u00a0 \u00a0<xp:eventHandler event=\"onclick\" submit=\"true\"\r\n   refreshMode=\"partial\" refreshId=\"col1\" execMode=\"partial\"\/>\r\n<\/xp:button><\/pre>\n
1. \u00d6ffnen der XPage<\/h2>\n
19.02.2012 18:23:17\u00a0 \u00a0HTTP JVM: Before phase: RENDER_RESPONSE 6\r\n19.02.2012 18:23:17\u00a0 \u00a0HTTP JVM: 1329672197161 You shall not refresh<\/strong>\r\n19.02.2012 18:23:17\u00a0 \u00a0HTTP JVM: After phase: RENDER_RESPONSE 6<\/pre>\n
2. Partial Refresh<\/h2>\n
19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: Before phase: RESTORE_VIEW 1\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: After phase: RESTORE_VIEW 1\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: Before phase: APPLY_REQUEST_VALUES 2\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: After phase: APPLY_REQUEST_VALUES 2\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: Before phase: PROCESS_VALIDATIONS 3\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: After phase: PROCESS_VALIDATIONS 3\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: Before phase: UPDATE_MODEL_VALUES 4\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: After phase: UPDATE_MODEL_VALUES 4\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: Before phase: INVOKE_APPLICATION 5\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: After phase: INVOKE_APPLICATION 5\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: Before phase: RENDER_RESPONSE 6\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: 1329672198875 You shall not refresh<\/strong>\r\n19.02.2012 18:23:18\u00a0 \u00a0HTTP JVM: After phase: RENDER_RESPONSE 6<\/pre>\n
Selbst das Setzen der\u00a0execId<\/em>\u00a0auf\u00a0col1<\/em>\u00a0\u00e4ndert nichts – der Refresh f\u00fchrt immer zu einer Neuberechnung der DataTable.<\/p>\n
Da diese Neuberechnung bei jedem Partial Refresh ausgel\u00f6st wird, werden Applikationen extrem ausgebremst. Daher sollte die Berechnung der Datenquelle wenn m\u00f6glich auf „Computed On Page Load<\/em>“ gesetzt werden.<\/p>\n
Wenn dies nicht m\u00f6glich ist, habe ich hier ein kleines Snippet, das die Berechnung nur dann durchf\u00fchrt, wenn die Datenquelle auch wirklich refresht wird:<\/p>\n
<xp:repeat id=\"repeat1\" rows=\"30\" var=\"rCol\">\r\n\u00a0\u00a0 <xp:this.value><![CDATA[#{javascript:\r\n\u00a0\u00a0 \u00a0 \u00a0function calculate(){\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 var data:java.util.Vector = new java.util.Vector();\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 data.add(java.lang.System.currentTimeMillis());\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 return data;\r\n\u00a0\u00a0 \u00a0 \u00a0}\r\n\r\n\u00a0\u00a0 \u00a0 \u00a0if( viewScope.containsKey(\"data\") == false){\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 viewScope.data = calculate();\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 return viewScope.data;\r\n\u00a0\u00a0 \u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0 \u00a0if( com.ibm.xsp.ajax.AjaxUtil.isAjaxPartialRefresh(facesContext) === true ){\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 var pId = com.ibm.xsp.ajax.AjaxUtil.getAjaxComponentId( facesContext \u00a0);\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 if( pId !== getClientId( 'repeat1' ) )\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0return viewScope.data;\r\n\u00a0\u00a0 \u00a0 \u00a0}\r\n\r\n\u00a0\u00a0 \u00a0 \u00a0viewScope.data = calculate();\r\n\u00a0\u00a0 \u00a0 \u00a0viewScope.data}]]>\r\n\u00a0\u00a0 <\/xp:this.value>\r\n\u00a0\u00a0 <xp:label value=\"#{javascript:rCol }\" id=\"label1\"><\/xp:label>\r\n<\/xp:repeat><\/pre>\n
[Hier ein Beispiel mit einem Repeat Control]<\/em><\/p>\n
Die Version ist recht simpel aufgebaut, eine verbesserte Version werde ich in den n\u00e4chsten Tagen als XSnippet ver\u00f6ffentlichen.<\/p>\n","protected":false},"excerpt":{"rendered":"
Dank einer Frage von Ulrich Krause im XPages Developer Forum wurde ein Thema „wiederbelebt“, das mir vor einiger Zeit in einem Projekt aufgefallen ist und sich als wahre Bremse bei XPages-Applikationen herausstellt: S\u00e4mtliche Datenquellen (DataContext-Variablen, Repeat Controls, usw.) werden bei … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,26,27,76,74],"tags":[34,33,7,30,88,86,87,5,3],"class_list":["post-572","post","type-post","status-publish","format-standard","hentry","category-expression-language","category-jsf","category-performance","category-ssjs","category-xpages","tag-8-5-2","tag-8-5-3","tag-domino","tag-el","tag-expression-language","tag-jsf","tag-performance","tag-ssjs","tag-xpages"],"_links":{"self":[{"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=\/wp\/v2\/posts\/572","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=572"}],"version-history":[{"count":4,"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=\/wp\/v2\/posts\/572\/revisions"}],"predecessor-version":[{"id":575,"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=\/wp\/v2\/posts\/572\/revisions\/575"}],"wp:attachment":[{"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=572"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=572"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hasselba.ch\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}