JSF - RichFaces performance problems showing complex page

I am working on Weblogic 10.3.2, JSF 1.2, Richfaces 3.3.2 and Facelets 1.1.14.

I have a serious performance problem, particularly showing my home page, which contains a very complex rich:datatable. When deploying the application on my local server, a request can take over 5 seconds to complete.

The home page is a ui:composition of a simple template (the problem is not in the template, the other pages are reasonably fast), but the composition itself is huge (~1000 lines).

The page has two parts, the lower part is a complex datatable, where I have implemented rowspan using a combination of multiple rich:subTables and the rendered attribute. The methodology followed can be seen in this Richfaces forum discussion.

The upper part of the page contains a list of filters for the datatable. I do not use filters in the rich:datatable headers, because I wanted something in the following fashion.

If the Add button is pressed, an AJAX request takes place (a4j:commandButton) to add another Filter object to the backing collection, and then filters are rerendered using a4j:repeat (not the datatable).

The rich:datatable is only rerendered when the Search button is pressed.

The code of my page is at the end of the post (some fields have been renamed).

Observations:

Modifying BalusC's Debug Phase Listener, I was able to see how much each phase takes. This is the request when pressing the "Add" button, where only the filters above the datatable are rendered.

2010-09-21 11:23:41,235 - Processing new Request!
2010-09-21 11:23:41,235 - before - RESTORE_VIEW 1
2010-09-21 11:23:41,235 - after - RESTORE_VIEW 1
2010-09-21 11:23:41,251 - before - APPLY_REQUEST_VALUES 2
2010-09-21 11:23:41,454 - getRowData-16: 84,026 ms
Home Page Query-16: 58,178 ms
2010-09-21 11:23:42,360 - after - APPLY_REQUEST_VALUES 2
2010-09-21 11:23:42,360 - before - PROCESS_VALIDATIONS 3
2010-09-21 11:23:42,438 - getRowData-16: 0,005 ms
2010-09-21 11:23:43,126 - after - PROCESS_VALIDATIONS 3
2010-09-21 11:23:43,126 - before - UPDATE_MODEL_VALUES 4
2010-09-21 11:23:43,188 - getRowData-16: 0,005 ms
2010-09-21 11:23:43,938 - after - UPDATE_MODEL_VALUES 4
2010-09-21 11:23:43,938 - before - INVOKE_APPLICATION 5
2010-09-21 11:23:43,938 - after - INVOKE_APPLICATION 5
2010-09-21 11:23:43,954 - before - RENDER_RESPONSE 6
2010-09-21 11:23:44,282 - getRowData-16: 0,007 ms
2010-09-21 11:23:45,173 - after - RENDER_RESPONSE 6
2010-09-21 11:23:45,173 - Done with Request!

You can see that the Apply Request Values takes about 0.8s, the Process Validations takes about 0.8s, the Update Model takes 0.8s, the Invoke Application (where the business logic takes place) takes negligible time and finally, the Render Response takes 0.9s.

When I comment out the rich:datatable and only show the filters, rendering is significantly faster:

2010-09-21 11:50:52,780 - Processing new Request!
2010-09-21 11:50:52,780 - before - RESTORE_VIEW 1
2010-09-21 11:50:52,780 - after - RESTORE_VIEW 1
2010-09-21 11:50:52,780 - before - APPLY_REQUEST_VALUES 2
2010-09-21 11:50:52,858 - after - APPLY_REQUEST_VALUES 2
2010-09-21 11:50:52,858 - before - PROCESS_VALIDATIONS 3
2010-09-21 11:50:52,920 - after - PROCESS_VALIDATIONS 3
2010-09-21 11:50:52,920 - before - UPDATE_MODEL_VALUES 4
2010-09-21 11:50:52,967 - after - UPDATE_MODEL_VALUES 4
2010-09-21 11:50:52,967 - before - INVOKE_APPLICATION 5
2010-09-21 11:50:52,967 - after - INVOKE_APPLICATION 5
2010-09-21 11:50:52,983 - before - RENDER_RESPONSE 6
2010-09-21 11:50:53,186 - after - RENDER_RESPONSE 6
2010-09-21 11:50:53,186 - Done with Request!

The whole request only took 400ms.

Questions:

1. Is this performance problem a JSF component tree issue?
2. I don't think that breaking up the page into other ui:compositions would help开发者_Python百科. I believe that this would result in an identical JSF component tree.

3. What can I do to make the page faster?

   The code: in PasteBin

You've a pretty complex component tree with multiple large tables, all planted in a single <h:form>. Whenever you submit some stuff related to a certain table/fieldgroup, then everything in the page will be submitted, also the values which are not apparently of interest for the particular request.

I think it would help a lot if you split The Big Form into several smaller forms, containing only the fields which are of real interest for the invoke action of the particular request.

I found a couple of articles by Dan Allen (Seam in Action) that are right to the point:

Part1

Part2

We had the exact same problem. Finally we realized that it was because of the simple page load was taking more time in the page load itself.

It turned out that it was because the simple JS load HTTP request was taking long and moreover it was not coming out of CDN.

We fixed it by moving the JS out of the deployment war and enabling the compression on JBoss.

Here is a detailed blog entry about how we fixed it:

http://tudip.blogspot.in/2012/03/how-to-really-improve-jsfrichfaces.html

Hope it helps.