Hello David, One easy way to get the page size is to use a browser plugin like Firebug or HttpWatch. They'll show you all of the requests for a particular page and how large they are. Chrome and Safari have decent tools built-in. Obviously this won't work for every single page, but it'll give you an idea if you look at some of your slowest pages. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3
* Listen to the latest headlines in the JSF and Java EE newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast * Keep up with the aftermath of the Oracle/Sun merger: http://www.mergerspeak.com On Wed, Oct 19, 2011 at 8:51 AM, Boyd, David (Corporate) < [email protected]> wrote: > Each page is different of course, some have lots of parts where others > are straight forward. > > We are using myFaces 1.1.7 and Tomahawk 1.1.5. > > Is there a way to capture how large each page is after it has been > compiled and rendered? > > > > -----Original Message----- > From: Kito Mann [mailto:[email protected]] > Sent: Tuesday, October 18, 2011 11:31 AM > To: MyFaces Discussion > Subject: Re: My Faces Tunning > > Hello David, > > How large are your pages? Do you have several tabs each with nested tabs > and > lots of fields? Which component suite(s) are you using? > --- > Kito D. Mann | twitter: kito99 | Author, JSF in Action > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and > consulting > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | > twitter: > jsfcentral > +1 203-404-4848 x3 > > * Listen to the latest headlines in the JSF and Java EE newscast: > http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+ > Newscast > * Keep up with the aftermath of the Oracle/Sun merger: > http://www.mergerspeak.com > > > > On Mon, Oct 17, 2011 at 4:16 PM, Boyd, David (Corporate) < > [email protected]> 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. > > > > >
