We tend to run higher sizes for our users. Currently running at 4M but as high as 25M.
But it is good to see some real numbers and possible targets/guidelines that we should be shooting for. Thanks -David Boyd (Sent via BlackBerry) ----- Original Message ----- From: Mark Struberg [mailto:strub...@yahoo.de] Sent: Tuesday, October 18, 2011 04:58 PM To: MyFaces Discussion <users@myfaces.apache.org> Subject: Re: My Faces Tunning +1 mem is barely a problem these days. Actually we are serving 60.000++ users per day without any mem problems (w 100 views/session ServerSide-StateSaving). We need some low GB mem on our 48GB RAM server... Even if you have 1MB of session mem per user then you can serve tons of users. LieGrue, strub >________________________________ >From: Tobias Eisentrager <teisentrae...@googlemail.com> >To: MyFaces Discussion <users@myfaces.apache.org> >Sent: Tuesday, October 18, 2011 10:46 PM >Subject: Re: My Faces Tunning > >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. >> > >> > >> >> > > >
