The app I'm working on is currently using STATE_SAVING_METHOD=client, because, at the time our code was written, that was the only way to handle the back-button (and pop-up windows) correctly. Can I assume from some of the notes that have been passed around that:
1. We can now use STATE_SAVING_METHOD=server, and the back-button (and pop-up windows) will work correctly (e.g., when my pop-up window closes, my base window won't have forgotten its state)? 2. Using STATE_SAVING_METHOD=server is faster and thus recommended? Just wondering what the current state of affairs is regarding the tradeoffs between server and client state saving method. - Brendan -----Original Message----- From: Mathias Brökelmann [mailto:[EMAIL PROTECTED] Sent: Friday, November 04, 2005 2:18 AM To: MyFaces Discussion Subject: Re: Some notes of my loadtest results If this setting is set to false the user might have some strange effects if multiple browser windows are used. IMO functionality is more important than performance which is the reason to have true as the default value. 2005/11/3, Travis Reeder <[EMAIL PROTECTED]>: > Shouldn't it default to SERIALIZE_STATE_IN_SESSION = false if it's > such a performance killer? > > Travis > > On 11/3/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > > SERIALIZE_STATE_IN_SESSION and NUMBER_OF_VIEWS_IN_SESSION are only > > effective if STATE_SAVING_METHOD=server otherwise it´s settings will > > be ignored. > > > > The default for SERIALIZE_STATE_IN_SESSION is true and > > NUMBER_OF_VIEWS_IN_SESSION is 20 and are recommended if you use > > STATE_SAVING_METHOD=server to avoid strange side effects. > > > > 2005/11/3, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]>: > > > > > > So is there enough information at the moment to make a recommendation > > > about > > > how to set the parameters? For example: > > > > > > 1. If I set STATE_SAVING_METHOD=client, should I then set > > > SERIALIZE_STATE_IN_SESSION=false? > > > > > > 2. If I set STATE_SAVING_METHOD=server, should I then set > > > SERIALIZE_STATE_IN_SESSION=true? > > > > > > - Brendan > > > > > > -----Original Message----- > > > From: Vesa Lindfors [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 03, 2005 1:51 AM > > > Cc: MyFaces Discussion > > > Subject: Re: Some notes of my loadtest results > > > > > > > > > Hi, > > > > > > I have now tested org.apache.myfaces.SERIALIZE > > > _STATE_IN_SESSION=false - and it worked like charm in the same Itanium > > > environment the earlier test of nightly build was giving bad results. > > > Average response time was now 116ms and no high load on processors. > > > > > > I also tried > > > org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true & > > > org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION=3. > > > It gave bad results (average 19419 ms and lot of load) again - but that > > > was > > > expected as the memory or garbage collection was not the problem earlier, > > > just processor load. > > > > > > We are using t:saveStates in our application, and I'm not sure if > > > SERIALIZE_STATE_IN_SESSION had effect when I tried to update-operation of > > > same pojo (pojo moved between pages with t:saveState) in two different > > > views, sometimes hibernate gave nicely announcement (with later update > > > operation) that data is stale and sometimes not, but it could also be some > > > caching issue or something - must be checked later.. > > > Can you please give me an example when I can expect some issues with > > > SERIALIZE_STATE_IN_SESSION=false ? > > > > > > Anyway, I can now continue testing 100 users with this setup in other > > > platforms (Solaris, HP-UX, AIX, Compaq and Linux) - thanks! > > > > > > --- VLi --- > > > > > > > > > On 11/3/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > > > > @Vesa could you run your tests again with the nightly and define the > > > > context param > > > org.apache.myfaces.SERIALIZE_STATE_IN_SESSION with a > > > > value set to false in your web.xml? > > > > > > > > You can also try to change the setting for > > > > org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION which > > > defines how many > > > > views are held in the session (default = 20). This might cause a > > > > garbage collector problem if memory is limited. > > > > > > > > Thanks a lot for your tests! > > > > > > > > 2005/11/2, Vesa Lindfors <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > We have small CRUD application that I have started to load-test in > > > > > different platforms. I'm using Myfaces impl + hibenate + Java 1.4.2. > > > > > > > > > > Test-case 1 (25% of users): Login - Creation of pojo and storing it to > > > db - > > > > > Listing pojos in db- - Search of created pojo - Remove of created > > > > > pojo - > > > > > Search of removed pojo - Logout . > > > > > Test-case 2 (75% of users): Login - Listing pojos in db - Search of > > > some > > > > > pojos - Logout. > > > > > > > > > > Tester is run with 100 threads (=users) and set to use 20 +-10 > > > > > seconds > > > > > delay per page to simulate end users actions. > > > > > "Ramp times" are set so that there is one logging-in per second. > > > > > > > > > > I noticed that application is really slow already in first tests. It > > > > > is > > > not > > > > > so bad in my Win laptop, but same application is really too much for 4 > > > > > processor HP-itanium or 20 processor solaris machine (both few years > > > old). > > > > > Slowness is due to application's processor capacity usage in machines. > > > > > Memory or garbage collection is not the issue. > > > > > After while there is hardly any "IDLE" capasity and machines start to > > > use > > > > > plenty of "SYS" time. Response times are after that really long. > > > > > This can be achieved just by running those 100 users once. > > > > > > > > > > > > > > > During development we have used "STATE_SAVING_METHOD=client". > > > > > When turning to "STATE_SAVING_METHOD=server", load problems > > > > > disappears. > > > > > This was tested with Myfaces-all.jar 1.1.1. > > > > > > > > > > > > > > > When I noticed that with nightly build it is now possible to use > > > > > server > > > > > side state saving, and still having multiple browser views (=tabs). > > > > > So I decided to test that possibility also. > > > > > > > > > > > > > > > Following HP-Itanium result lines describes how stalled the machine > > > > > has > > > > > been with client side state saving. > > > > > And that there is maybe similar problems in the NB version of server > > > side > > > > > state saving: > > > > > > > > > > 1.1.1 average response time when "STATE_SAVING_METHOD=server ": > > > > > 145 ms > > > > > > > > > > 1.1.1 average response time when "STATE_SAVING_METHOD= client": > > > > > 82358 ms -> > 80 seconds > > > > > > > > > > 20051030NB average response time when "STATE_SAVING_METHOD=server": > > > 32440 > > > > > ms -> >32 seconds > > > > > > > > > > Results are sad because 100 really friendly users is not really so > > > > > much > > > for > > > > > web app - average throughput was only 2,5/second in successfully > > > > > server-side-case. > > > > > The application is also pretty simple, although it's having > > > > > searchable-sortable-pageable table. > > > > > > > > > > > > > > > Has anyone got similar kind of results? Br > > > > > -- VLi -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Mathias > > > > > > > > > > > > > > > > -- > > Mathias > > > -- Mathias
