> - Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support > the browser back button!
And once a user opens another browser tab all will crash :( The missing windowId support is really a pitty in the JSF spec, and we currently think hard about how to solve this (at least in MyFaces). Until then all the stored views are shared accross all open browser tabs. The best thing you can do to reduse Session space is to use ClientSideStateSaving LieGrue, strub ----- Original Message ----- > From: Michael Heinen <mhn4...@googlemail.com> > To: MyFaces Discussion <users@myfaces.apache.org> > Cc: > Sent: Tuesday, October 18, 2011 9:36 AM > Subject: Re: My Faces Tunning > > A few thoughts: > - Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support > the browser back button! > - try to reduce the number of components (e.g. conditionally controls > can be excluded at compile time via c:if or via dynamic includes instead > of visibleOnUserRole or rendered checks). > - facelets instead of jsps > - plain html tags where possible > - short component ids > > Michael > > > > Am 17.10.2011 22:16, schrieb Boyd, David (Corporate): >> All, >> >> >> >> I am doing some investigation into how to shrink the amount of session >> memory our JSF application is consuming on a per user basis. >> >> >> >> We are using MyFaces 1.1.7 and Tomahawk 1.1.5 running on IBM Websphere >> 7.0 patch 19. (Not able to upgrade either of these items at this time) >> >> >> >> IBM's guideline is that the session size should be less then 5k - >> average around 2.5k in order not to impact performance of the server and >> session replication. We are currently using Memory to Memory but >> looking at moving to database as suggested by IBM. >> >> >> >> Our site was running at about 35M per user. We changed the number of >> view states from 100 to 10 and that dropped it down to around 4M. >> >> >> >> We have several backing beans which are currently session scope and are >> looking at changing them to request scope. >> >> >> >> I also found the following: >> http://www.econsulting.nl/images/pdf/Tuning%20JSF%20Applications-%20J-Sp >> ring%202008.pdf which seems to have a lot of information concerning how >> JSF handles certain content on the pages. This is still under >> investigation to make sure what is stated make sense. >> >> >> >> I have also read somewhere that regardless if the managed backing bean >> is session or request scope is that the view state will still have the >> bean and its content. So the view state size will not change. Looking >> for clarification on this one. >> >> >> >> The questions is are others facing the same issue in which JSF >> applications tend to consume a lot of memory for a given users session? >> >> >> >> >> What are some of the best practices to reduce this size if any or is >> this just the way when using JSF? >> >> >> >> Issues with session replication on IBM WebSphere when running a JSF >> application? >> >> >> >> What we see as a result of this is that in the event a user hops to >> another server, the session data is not present due to how large the >> data is and how long it takes to replicate. User experience issues. >> >> >> >> We had seen an issue in which it appeared that changes to the object in >> the session was not being updated correctly and have done some session >> management tuning in which we customize the settings so that all session >> attributes are written out. Looking at the .jar file it does appear >> that myFaces is making the call correctly when the contents of the >> object in the session changes. So WebSphere session listener should be >> picking up that change. >> >> >
