Last year I posted about some helpful advice I found on JSF performance. Sadly, those slides are no longer available. So I’m putting the details that I remember in this post.
JSF keeps lots of information about the current page and previous pages in the JSF state object. This allows all of the Faces components to keep track of their state, and also allows the back button to work. (Why this is all needed is a long story which I’m not 100% sure I understand completely, so I won’t try to get into it.)
Unfortunately, that can add up to a lot of information. It an either be serialized and stored with the client (which can add up to a lot of data), or stored in the session on the server. I find the server configuration works better, and I think Mr. Klaver recommended the same thing.
To use it, add this to your web.xml:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
The real issue, though, is how big the session data structure can get. In one app we found that the sessions quickly could grow to tens of megabytes each with the default settings. The issue is that for every page that needs a back button to work, Faces needs to keep the entire view data for that page, and the default is 15 pages.
Frankly, I think this is a design weakness of Faces, but it’s one that I’ve found I can live with.
The settings Mr. Klaver recommended adjusting are:
<!– Keep you session memory from exploding !: http://www.nljug.org/~tukker/jspring2008_jsf.pdf –>
<context-param>
<param-name>com.sun.faces.numberOfViewsInSession</param-name>
<param-value>3</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>10</param-value>
</context-param>
The numberOfViewsInSession parameter is the big one – this only allows three back buttons inside a faces form. I’ve actually had good luck with setting it to 1, and using more links than faces navigation, but on other apps I’ve needed to set up as high as three or four for the app to feel right.
Hi, Andrew:
Thank you for your posting, it is really helpful.
Now I am designing a new web application which has large transaction volume, complex user flow and large amount of data. I am wondering if I should use JSF, Structs, or Spring MVC and Web Flow.
I am kind of worried there will be perforamnce issue if I use JSF. If I follow you strategy to resolve the big session object issue, is that mean the major performance issue of JSF could be resolved?
Thanks,
Julia Liang
Hi Julia,
I think you will find JSF performs quite well. I’ve used it on a couple of sites now, and I’ve been quite happy with the performance.
I haven’t used Web Flow, so I can’t say anything about that. Struts is going to be a bit lighter than JSF if you’re just using the MVC part of it. I’ve only done a bit with the forms aspect, but I don’t think JSF is going to be particularly slower.
One other caveat I will add with JSF – it can be quite a pain to build forms with hierarchical data. For instance if you want to build a screen that has a variable number of rows of editable data. The main thing is to tie every JSF component to a specific bean, and keep those beans in session scope. There’s not a really easy way for JSF to identify individual backing beans among a collection of beans if you’re using request scope.
Good luck, and let me know if you run into any problems.
Cheers,
Andrew