The reason why the state is now serialized into the session is to support multiple views when state is saved on server. The problem I see if it is turned off is t:savestate which saves the state of a bean as a part of the view state. If we don´t serialize this bean it will be shared among the views. This will cause problems.
I will make some performance test to find out which part of the new implementation is causing this. 2005/11/2, Travis Reeder <[EMAIL PROTECTED]>: > Very interesting. > > Martin: Why does it serialize the state in the session? And if that's > turned off, what is the behaviour? > > Travis > > On 11/2/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > > quite interesting. > > > > I guess it has something todo with the introduced serialisation for > > the nightly if server side state is used. myfaces introduced a context > > parameter which allows the user to switch this new behavior off (it´s > > on by default). Define org.apache.myfaces.SERIALIZE_STATE_IN_SESSION > > as a context parameter for your web-app in web.xml to avoid the > > serialization. > > > > 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
