All,
I am doing some research on how to reduce the amount of session memory that a JSF application uses for each user.
We are using MyFaces 1.1.7 and Tomahawk 1.1.5, running on the IBM Websphere 7.0 19 patch. (Failed to update any of these elements at this time)
The IBM leadership is that the session size should be less than 5k - an average of about 2.5 thousand, so as not to affect server performance and session replication. We currently use Memory to Memory, but are looking at moving to the database, as IBM suggests.
Our site ran about 35M per user. We changed the number of view states from 100 to 10, and this reduced it to 4M.
We have several fallback beans, which are currently a session scope and are looking to change them to query the scope.
I also found the following: http://www.econsulting.nl/images/pdf/Tuning%20JSF%20Applications-%20J-Spring%202008.pdf , which seems to contain a lot of information on how JSF processes certain content on pages. This is still under investigation to make sure that it says it makes sense.
I also read somewhere that regardless of whether the managed backup bean is a session or query area, the view state will still contain the bean and its contents. Thus, the size of the view will not change. Looking for clarification on this.
Questions relate to the same issues in which JSF applications tend to consume a lot of memory for a given user session?
What are some of the best practices to reduce this size, if any, or is it just a way to use JSF?
Problems with session replication in IBM WebSphere when starting a JSF application?
Is there any documentation on how JSF / MyFaces uses heap memory - Young vs old or should it be considered in this area? Tuning tuning garbage?
What we see as a result of this is that if the user moves to another server, there is no session data due to how big the data is and how long it takes for replication. Problems with the user interface.
We saw a problem in which it turned out that the changes in the object in the session were not updated correctly and made some session management settings in which we configure the parameters so that all session attributes are written out. Looking at the .jar file, it looks like myFaces is correctly making the call when the contents of the object in the session change. Therefore, the WebSphere session listener must pick up this change.