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 ---
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
