Search code examples
javajsfwebsphereperformance

JSF Tuning

Running into an issue where JSF is filling up our sessions. We had a system crash the other day. Sent the Heap to IBM for review and found that we had some sessions as large as 50M. They found JSF components in the session and some very large.

So, is there any tuning that can be done? Configuration items to look at? Or other direction.

Our system is build using JSF and Spring for the presentation layer, the back end is EJB, Spring and Hibernate all running on WebSphere 6.1.

Solution

  • JSF is a useful technology, but you can certainly hang yourself with it.

    It sounds like, either you're inflating the size of the view state (by setting large values on components) or you're leaking references to components into other session state (which would be bad). Another potential culprit would be an excessively large view (I've seen the ease with which people can build UI trees lead to very big control graphs with data tables everywhere). I know that IBM provides rich text and spreadsheet controls - I can't comment on what effect the use of these will have on state size.

    The low hanging fruit is to check the managed beans configured for session scope in faces-config.xml.

    JSF saves two things between requests:

    • the view (all the controls on the page)
    • the view state (the state of the controls)

    These are separated because some controls, such as children of a data table, can have multiple states (one for each row). State can be saved to either a hidden field on the form (which, if unencrypted, can be a big security hazard) or in the session. In order to accommodate multiple browser windows sharing the same session (and, in some implementations, back button support), multiple views are stored.

    • There should be a configuration option to set the number of view states the app will keep in the session for a given user at any given time.
    • You can measure the size of view state by providing a StateManager that measures the size of the saved view/state (configure a StateManager in faces-config.xml with a public constructor that takes a StateManager - see the JSF spec PDFs for more details; the state is serializable and you can check its size by dumping it to a stream).

    Most IDE-built JSF apps have backing beans. It would be possible, via session bean scope to hold onto state longer than you want, placing a strain on the session. Since there tends to be one backing bean per page, the more pages you have, the bigger the problem will be. Check your faces-config.xml to see if this is a potential source of problems.

    Something else you could do would be to configure a HttpSessionAttributeListener in your web.xml. You can get a stack trace to help identify problem areas in your app.