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 >
