David, Usually memory is the problem - but sometimes there are also CPU problems - you can run WebSphere for example on the Mainframe. Compared to a Linux Box CPU time can be expensive there.
Are you running on a 64 bit Architecture? Memory is not that expensive these days ;-) What is you total memory usage? Toby On Tue, Oct 18, 2011 at 10:42 PM, Boyd, David (Corporate) < david.b...@adesa.com> wrote: > Scott, > > With your comment below but do you feel is a more realistic targeted > size for session size with JSF? > > All, > > Based on some of the comments, is this not an issue for others that make > use of this Technology or did we basically implement it incorrectly - > from the way the .jsp are created to how we are managing the backing > beans? > > > > -----Original Message----- > From: Scott O'Bryan [mailto:darkar...@gmail.com] > Sent: Monday, October 17, 2011 4:58 PM > To: users@myfaces.apache.org > Subject: Re: My Faces Tunning > > Wow.. Looks like you've done a lot, but I personally think 5K is > unrealistic. Your right. Essentially JSF stores your component tree in > > memory. > > You MAY be able to enable client-side state saving which should free you > > up some memory at the expense of storing the entire view tree on the > client. Additionally, a framework like orchestra or something home > grown may allow you to get rid of managed beans quicker. > > One other thing. I don't know how Websphere works, but I know in the > case of WLS, it only serializes object when they are added to the > session. While this means they may need to be added again if they are > updated, it's not subject to this limitation your describing. I'm > wondering if WebSphere has some settings on the replication which might > get you some better results. > > Scott > > On 10/17/2011 02:16 PM, Boyd, David (Corporate) wrote: > > 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. > > > > > >