@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
