You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "Boyd, David (Corporate)" <Da...@adesa.com> on 2011/10/17 22:16:58 UTC
My Faces Tunning
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.
Re: My Faces Tunning
Posted by Kito Mann <ki...@virtua.com>.
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) <
David.Boyd@adesa.com> 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:kito.mann@virtua.com]
> 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) <
> David.Boyd@adesa.com> 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.
> >
> >
>
RE: My Faces Tunning
Posted by "Boyd, David (Corporate)" <Da...@adesa.com>.
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:kito.mann@virtua.com]
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) <
David.Boyd@adesa.com> 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.
>
>
Re: My Faces Tunning
Posted by Kito Mann <ki...@virtua.com>.
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) <
David.Boyd@adesa.com> 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.
>
>
RE: My Faces Tunning
Posted by "Boyd, David (Corporate)" <Da...@adesa.com>.
If we go with client side state saving what kind of performance hit can we expect?
Going this route does this make assumptions on the type of machine a user has? The browser that they are using?
>From the myFaces wiki, I see that if we go with client side we have the issue of serialization.
At this point can someone point me to a good reference in order for me to understand the life cycle of JSF request/response to see how all this plays out?
-----Original Message-----
From: Mark Struberg [mailto:struberg@yahoo.de]
Sent: Tuesday, October 18, 2011 4:01 AM
To: MyFaces Discussion
Subject: Re: My Faces Tunning
> - 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 <mh...@googlemail.com>
> To: MyFaces Discussion <us...@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.
>>
>>
>
Re: My Faces Tunning
Posted by Mark Struberg <st...@yahoo.de>.
> - 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 <mh...@googlemail.com>
> To: MyFaces Discussion <us...@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.
>>
>>
>
Re: My Faces Tunning
Posted by Michael Heinen <mh...@googlemail.com>.
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.
>
>
RE: My Faces Tunning
Posted by "Boyd, David (Corporate)" <Da...@adesa.com>.
Mark,
Can you tell me what application server you are using?
Are you using any session replication and if so what kind?
What OS are you using?
Are you using Session Affinity?
What JSF implementation are you using?
We are using myFaces 1.1.7 and Tomahawk 1.1.5 (old and not able to upgrade at this point).
Thanks
-----Original Message-----
From: Mark Struberg [mailto:struberg@yahoo.de]
Sent: Tuesday, October 18, 2011 4:58 PM
To: MyFaces Discussion
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 <te...@googlemail.com>
>To: MyFaces Discussion <us...@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.Boyd@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:darkarena@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.
>> >
>> >
>>
>>
>
>
>
Re: My Faces Tunning
Posted by "Boyd, David (Corporate)" <Da...@adesa.com>.
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:struberg@yahoo.de]
Sent: Tuesday, October 18, 2011 04:58 PM
To: MyFaces Discussion <us...@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 <te...@googlemail.com>
>To: MyFaces Discussion <us...@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.Boyd@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:darkarena@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.
>> >
>> >
>>
>>
>
>
>
Re: My Faces Tunning
Posted by Mark Struberg <st...@yahoo.de>.
+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 <te...@googlemail.com>
>To: MyFaces Discussion <us...@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.Boyd@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:darkarena@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.
>> >
>> >
>>
>>
>
>
>
Re: My Faces Tunning
Posted by "Boyd, David (Corporate)" <Da...@adesa.com>.
We are running under Red Hat with WebSphere 7 64-Bit.
Currently heap is set to 8 G. The issue seems to be around the ability of the server to replicate the data across all the servers. We get complaints from the users of lost information during a server hop
Thanks
-David Boyd
(Sent via BlackBerry)
----- Original Message -----
From: Tobias Eisentrager [mailto:teisentraeger@googlemail.com]
Sent: Tuesday, October 18, 2011 04:46 PM
To: MyFaces Discussion <us...@myfaces.apache.org>
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.Boyd@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:darkarena@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.
> >
> >
>
>
Re: My Faces Tunning
Posted by Tobias Eisentrager <te...@googlemail.com>.
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.Boyd@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:darkarena@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.
> >
> >
>
>
RE: My Faces Tunning
Posted by "Boyd, David (Corporate)" <Da...@adesa.com>.
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:darkarena@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.
>
>
Re: My Faces Tunning
Posted by Werner Punz <we...@gmail.com>.
Still (I know it is not an option) but if you need to reduce session
space JSF 2 is the way to go, the delta state saving can free a load of ram.
Werner
Am 10/17/11 10:58 PM, schrieb Scott O'Bryan:
> 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.
>>
>>
>
>
Re: My Faces Tunning
Posted by Scott O'Bryan <da...@gmail.com>.
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.
>
>