Actually, Werner Punz was working on something like a server side saveState tag which uses a phase listener to store and restore the data - it is checked into the sandbox.
Maybe we could merge the functionality to have a saveState that also works without restore/saveState being called and therefore also works with the RI, saving processing time along the way? regards, Martin On 11/2/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > 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 > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
