JSF1 RichFaces Performance Tuning

1) JSF components tree state takes big enough memory. In the server-side
state saving ( default JSF behavior ) these objects are stored in the
session. For a many concurrent user connections every user gets own
session object. Possible solution - switch to the client-side state saving.
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>

Other possible solution is Facelets behavior that allows to build view
before request processing instead of state saving, but that solution has
sometimes unpredictable side effects. Use web.xml init parameter
together with the <f:view transient="true" > attribute.
<context-param>
<param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
<param-value>true</param-value>
</context-param>
As an intermediate solution, it is makes sense to create custom FaceletsViewHandler subclass with special state processing for a some pages like menus which does not depends for a saved state. That custom handler could call buildView method instead of real restoreView procedure for a such pages.
2) Facelets library in the "debug" mode stores information about
components and beans up to 5 times for an every user. To disable this mode:
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>

3) Most filters use buffering for request processing. According to the
profile information, these buffers took big enough memory in the
application. I see a buffer-related parameter in the RichFaces Ajax filter:
<init-param>
<param-name>maxRequestSize</param-name>
<param-value>100000</param-value>
</init-param>
For a production server, it makes sense to reduce value to a real page
size or remove that parameter at all.
4) TIDY xml filter is DOM-based, thus it requires a lot of memory. It
would be better to use more optimized "NONE" or "NEKO" one :
<context-param>
<param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
<param-value>NONE</param-value>
</context-param>

JSF Thing to cater for if you are JSF Developer

It is because JSF is component base(not simple as MVC direct request to action in controller layer).

Problem of coding style

1) DB query inside getter method of backing bean.

public List getUserRole(){
return userRoleDao.queryAllUserRole();
}

Issue : Getter may be call in restore view or apply request value or render response phase

• Table component, it wil cause the data being query 2 times.
• inputText/radio etc. component, it will check the previous submitted value store(JSF will store previous submitted value automatically) inside the inputText. If it is null, it will call the getter in backing bean to retrieve the value.

Following was the log.
[ INFO] 29-07-09 11:10:34 : BEFORE RESTORE_VIEW(1)
[ INFO] 29-07-09 11:10:34 : AFTER RESTORE_VIEW(1)
[ INFO] 29-07-09 11:10:34 : BEFORE APPLY_REQUEST_VALUES(2) Hibernate: select this_.role_name as ...
[ INFO] 29-07-09 11:10:34 : AFTER APPLY_REQUEST_VALUES(2)
[ INFO] 29-07-09 11:10:34 : BEFORE PROCESS_VALIDATIONS(3)
[ INFO] 29-07-09 11:10:34 : AFTER PROCESS_VALIDATIONS(3)
[ INFO] 29-07-09 11:10:34 : BEFORE UPDATE_MODEL_VALUES(4)
[ INFO] 29-07-09 11:10:34 : AFTER UPDATE_MODEL_VALUES(4)
[ INFO] 29-07-09 11:10:34 : BEFORE INVOKE_APPLICATION(5)
[ INFO] 29-07-09 11:10:34 : AFTER INVOKE_APPLICATION(5)
[ INFO] 29-07-09 11:10:34 : BEFORE RENDER_RESPONSE(6) Hibernate: select this_.role_name ...
[ INFO] 29-07-09 11:10:35 : AFTER RENDER_RESPONSE(6)

Solution : Only query DB when it is in render response phase.

public List getUserRole(){
if (FacesContext.getCurrentInstance().getRenderResponse())
return userRoleDao.queryAllUserRole();
else
return null;
}

or

public List getUserRole(){
if ( userRoleList!=null)
userRoleList = userRoleDao.queryAllUserRole();

return userRoleList;
}

JSF 2 going to have MVC lifecycle!!!

JSF 1 Immediate property

Immediate = true , it will no proceed to Validations phase. It suit for Cancel button that you don't want any validation(require=true etc.) on the page but it will reach to action of Cancel button. Since those parameters of inputText do not go through validation phase, it also will not update to your variable in backing bean. There is a workaround solution to retrieve those values.

hyperlink immediate = true. that only accepts values from a specific control (the immediate property for all of these components would be true).