You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Vesa Lindfors <ve...@gmail.com> on 2005/11/02 16:14:17 UTC
Some notes of my loadtest results
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 --
Re: Some notes of my loadtest results
Posted by Vesa Lindfors <ve...@gmail.com>.
Mathias, thanks for you patience.. I'll change from method binding to value
binding and continue load tests this week...
--- VLi ---
On 11/13/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
>
> Using t:savestate is not the solution.
>
> t:savestate holds the state between requests. The rowstates maintained
> by UIData are only created and used while processing the lifecycle of
> jsf. They are discarded at the end of each request.
>
> 2005/11/12, Yee CN <ye...@streamyx.com>:
> > Is it possible/appropriate to use
> > <t:saveState value=#{SubscrierMB.dataModel}>
> >
> > to solve the problem?
> >
> > Regards,
> > Yee
> >
> > -----Original Message-----
> > From: Mathias Brökelmann [mailto:mbroekelmann@googlemail.com]
> > Sent: Saturday, 12 November 2005 9:38 PM
> > To: MyFaces Discussion
> > Subject: Re: Some notes of my loadtest results
> >
> > You have a component binding. I mean the valuebinding through the
> > attribute value. I expect something like this:
> >
> > <h:selectBooleanCheckbox
> > ...
> > value="#{SubscriberMB.checkedRow}"
> > ... >
> > </h:selectBooleanCheckbox>
> >
> > The problem is still the same. Datatable maintains internal rowstates
> > which contains the setted values for each component and each row but
> > they are discared before render phase. The invoke application phase in
> > which you set the boolean value is before the render phase. Any value
> > you have set in the application phase through the component binding
> > will be lost since updateModel phase (which could set the value
> > through the value binding) is before invoke application.
> >
> >
> > 2005/11/12, Vesa Lindfors <ve...@gmail.com>:
> > > Sorry, I wasn't clear enough in problem description - sure I have
> > > valuebinding in each row:
> > > <h:selectBooleanCheckbox
> > > ...
> > > binding="#{SubscriberMB.checkedRow}"
> > > ... >
> > > </h:selectBooleanCheckbox>
> > > and that is working like earlier. I can select (one by one) and have
> > actions
> > > for selected users (selected by clicking checkboxes).
> > >
> > > On the other words, I failed to set checkboxes in table by programming
> > >
> > > dataModel.setRowIndex(index);
> > > checkedRow.setSelected(true);
> > >
> > > And I think that should work also?
> > > -- vLi --
> > >
> > >
> > >
> > > On 11/12/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > > > I wonder that this is working in 1.1.1.
> > > >
> > > > Normally the state for each row in a datatable is discarded before
> the
> > > > table is rendered if the page data contains no error. Any input
> > > > component without a valuebinding loses its value. I suggest you to
> use
> > > > a valuebinding for the UISelectBoolean field. This will work better
> in
> > > > datatables. If the selectall button is executed set the flags for
> the
> > > > managed bean field for each row which was bound to the select
> boolean
> > > > component.
> > > >
> > > > 2005/11/11, Vesa Lindfors <ve...@gmail.com>:
> > > > > I have just one more issue before I can test NB again with
> > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
> > > > >
> > > > > I had earlier (1.1.1) working "Select all" function for checkboxs
> in
> > my
> > > > > datatable, now in NB it's not (neither in cleint or server side).
> Is
> > > there
> > > > > any thing I should make differently?
> > > > >
> > > > > private UISelectBoolean checkedRow = null;
> > > > >
> > > > > public UISelectBoolean getCheckedRow() { return checkedRow; }
> > > > >
> > > > > public void setCheckedRow(UISelectBoolean checked) {
> this.checkedRow
> > =
> > > > > checked; }
> > > > >
> > > > > public void selectAllListener(ActionEvent event) {
> > > > > ...
> > > > > for (int index = first; index < rows; index++) {
> > > > > dataModel.setRowIndex(index);
> > > > > checkedRow.setSelected(true);
> > > > > }
> > > > > }
> > > > > ...
> > > > > }
> > > > >
> > > > > x:dataTable has preserveDataModel="false" and the data list stored
> by
> > > > > x:saveState.
> > > > >
> > > > > I can see that method is called properly and no exception is
> shown,
> > but
> > > the
> > > > > checkboxes are not marked as earlier...
> > > > >
> > > > > -- VLi ---
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11/9/05, Mathias Brökelmann <mbroekelmann@googlemail.com >
> wrote:
> > > > > > You are right latest commit breaks that. I have committed a fix
> for
> > > > > > that so it is working now.
> > > > > >
> > > > > > 2005/11/9, Vesa Lindfors < vesa.lindfors@gmail.com>:
> > > > > > > Mathias,
> > > > > > > I tested successfully the rest of platforms with
> > > > > > > javax.faces.STATE_SAVING_METHOD=server &&
> > > > > > > SERIALIZE_STATE_IN_SESSION=false &&
> > > myfaces-20051030 .
> > > > > > >
> > > > > > > Now I should have time to continue testing your suggestion:
> > > > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
> &&
> > > > > > > myfaces-20051103.
> > > > > > > But now my testing fails at the very begin: the application
> > didn't
> > > > > worked
> > > > > > > at all with state saving "server" - my ActionEvents weren't
> fired
> > at
> > > all
> > > > > ( I
> > > > > > > mean very basic form buttons didn't work anymore). Turning
> state
> > > saving
> > > > > to
> > > > > > > the "client" it start to work again. I tried also with
> > > myfaces-20051107
> > > > > and
> > > > > > > same results. Do you have any idea what could be changed in NB
> > > during
> > > > > > > 20051030- 20051103 so that it can have such effect?
> > > > > > >
> > > > > > > --- VLi ---
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >One more thing. I have removed the gzipping of the
> serialized
> > > stream
> > > > > > > > >if server side state is used. This might have caused some
> > > additional
> > > > > > > > >performance problems. Would it be possible to take the next
> > > nightly
> > > > > > > > >(20051103) and test it again with
> > > > > > > >
> > > >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true
> > > > > to
> > > > > > > check this?
> > > > > > > >
> > > > > > > > >Mathias
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mathias
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Mathias
> > > >
> > >
> > >
> >
> >
> > --
> > Mathias
> >
> >
>
>
> --
> Mathias
>
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
Using t:savestate is not the solution.
t:savestate holds the state between requests. The rowstates maintained
by UIData are only created and used while processing the lifecycle of
jsf. They are discarded at the end of each request.
2005/11/12, Yee CN <ye...@streamyx.com>:
> Is it possible/appropriate to use
> <t:saveState value=#{SubscrierMB.dataModel}>
>
> to solve the problem?
>
> Regards,
> Yee
>
> -----Original Message-----
> From: Mathias Brökelmann [mailto:mbroekelmann@googlemail.com]
> Sent: Saturday, 12 November 2005 9:38 PM
> To: MyFaces Discussion
> Subject: Re: Some notes of my loadtest results
>
> You have a component binding. I mean the valuebinding through the
> attribute value. I expect something like this:
>
> <h:selectBooleanCheckbox
> ...
> value="#{SubscriberMB.checkedRow}"
> ... >
> </h:selectBooleanCheckbox>
>
> The problem is still the same. Datatable maintains internal rowstates
> which contains the setted values for each component and each row but
> they are discared before render phase. The invoke application phase in
> which you set the boolean value is before the render phase. Any value
> you have set in the application phase through the component binding
> will be lost since updateModel phase (which could set the value
> through the value binding) is before invoke application.
>
>
> 2005/11/12, Vesa Lindfors <ve...@gmail.com>:
> > Sorry, I wasn't clear enough in problem description - sure I have
> > valuebinding in each row:
> > <h:selectBooleanCheckbox
> > ...
> > binding="#{SubscriberMB.checkedRow}"
> > ... >
> > </h:selectBooleanCheckbox>
> > and that is working like earlier. I can select (one by one) and have
> actions
> > for selected users (selected by clicking checkboxes).
> >
> > On the other words, I failed to set checkboxes in table by programming
> >
> > dataModel.setRowIndex(index);
> > checkedRow.setSelected(true);
> >
> > And I think that should work also?
> > -- vLi --
> >
> >
> >
> > On 11/12/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > > I wonder that this is working in 1.1.1.
> > >
> > > Normally the state for each row in a datatable is discarded before the
> > > table is rendered if the page data contains no error. Any input
> > > component without a valuebinding loses its value. I suggest you to use
> > > a valuebinding for the UISelectBoolean field. This will work better in
> > > datatables. If the selectall button is executed set the flags for the
> > > managed bean field for each row which was bound to the select boolean
> > > component.
> > >
> > > 2005/11/11, Vesa Lindfors <ve...@gmail.com>:
> > > > I have just one more issue before I can test NB again with
> > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
> > > >
> > > > I had earlier (1.1.1) working "Select all" function for checkboxs in
> my
> > > > datatable, now in NB it's not (neither in cleint or server side). Is
> > there
> > > > any thing I should make differently?
> > > >
> > > > private UISelectBoolean checkedRow = null;
> > > >
> > > > public UISelectBoolean getCheckedRow() { return checkedRow; }
> > > >
> > > > public void setCheckedRow(UISelectBoolean checked) { this.checkedRow
> =
> > > > checked; }
> > > >
> > > > public void selectAllListener(ActionEvent event) {
> > > > ...
> > > > for (int index = first; index < rows; index++) {
> > > > dataModel.setRowIndex(index);
> > > > checkedRow.setSelected(true);
> > > > }
> > > > }
> > > > ...
> > > > }
> > > >
> > > > x:dataTable has preserveDataModel="false" and the data list stored by
> > > > x:saveState.
> > > >
> > > > I can see that method is called properly and no exception is shown,
> but
> > the
> > > > checkboxes are not marked as earlier...
> > > >
> > > > -- VLi ---
> > > >
> > > >
> > > >
> > > >
> > > > On 11/9/05, Mathias Brökelmann <mbroekelmann@googlemail.com > wrote:
> > > > > You are right latest commit breaks that. I have committed a fix for
> > > > > that so it is working now.
> > > > >
> > > > > 2005/11/9, Vesa Lindfors < vesa.lindfors@gmail.com>:
> > > > > > Mathias,
> > > > > > I tested successfully the rest of platforms with
> > > > > > javax.faces.STATE_SAVING_METHOD=server &&
> > > > > > SERIALIZE_STATE_IN_SESSION=false &&
> > myfaces-20051030 .
> > > > > >
> > > > > > Now I should have time to continue testing your suggestion:
> > > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
> > > > > > myfaces-20051103.
> > > > > > But now my testing fails at the very begin: the application
> didn't
> > > > worked
> > > > > > at all with state saving "server" - my ActionEvents weren't fired
> at
> > all
> > > > ( I
> > > > > > mean very basic form buttons didn't work anymore). Turning state
> > saving
> > > > to
> > > > > > the "client" it start to work again. I tried also with
> > myfaces-20051107
> > > > and
> > > > > > same results. Do you have any idea what could be changed in NB
> > during
> > > > > > 20051030- 20051103 so that it can have such effect?
> > > > > >
> > > > > > --- VLi ---
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >One more thing. I have removed the gzipping of the serialized
> > stream
> > > > > > > >if server side state is used. This might have caused some
> > additional
> > > > > > > >performance problems. Would it be possible to take the next
> > nightly
> > > > > > > >(20051103) and test it again with
> > > > > > >
> > >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true
> > > > to
> > > > > > check this?
> > > > > > >
> > > > > > > >Mathias
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Mathias
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Mathias
> > >
> >
> >
>
>
> --
> Mathias
>
>
--
Mathias
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
well take a look into javadoc of UIData.encodeBegin() in the spec. It
says that the rowstates must be discarded in this method.
Some use cases still work by this approach. It´s ok to delete, edit or
add rows in the action
through the component binding of the selectboolean checkbox as long as
it only read the value of the component. But it will not work if you
write the value for the component.
2005/11/13, Vesa Lindfors <ve...@gmail.com>:
> Ok, what I'm doing is something Craig McClanahan has shown in
> http://forum.java.sun.com/thread.jspa?threadID=486654&messageID=2819434:
>
> "...
> The UIData control will take care of making sure that the correct MailBean
> is stored in the "var" element for each row. In the delete() method, you can
> simply walk through your list of MailBean beans and take action on the ones
> that have the "selected" property set.
>
> If you do not have a boolean property on the bean that you can use,
> Approach (2) is to bind your component directly into your backing bean ...
> something like this:
> <h:form id="mailbox">
> <h:data_table value="#{mailsForm.mails}" var="mailBean" binding=
> "#{mybean.table}">
> <h:column>
> <f:facet>
> <h:output_text value="Selected"/>
> </f:facet>
> <h:selectboolean_checkbox id=
> "selected" binding="#{mybean.selected}"/>
> </h:column>
> <h:column>
> <f:facet>
> <h:output_text value=
> "From"/>
> </f:facet>
> <h:output_text id="from" value="#{mailBean.from}"/>
> </h:column>
>
> ...
> </h:data_table>
> <h:command_button id="delete" action="#{mybean.delete}"/>
> </h:form>
>
>
> with a backing bean something like this:
> public class MyBean {
>
> // Property bound to the "selected" checkbox
>
> UISelectBoolean selected;
> public UISelectBoolean getSelected() {
> return selected;
> }
>
> public void setSelected(UISelectBoolean selected) {
> this.selected = selected;
> }
>
>
> // Property bound to the entire table
> UIData table;
> public UIData getTable() {
>
> return table;
> }
> public void setTable(UIData table) {
> this.table = table;
>
> }
>
> // Method to delete all the selected messages
> public String delete() {
>
>
> // Iterate through the data rows ...
> int first = table.getFirst();
> int rows = table.getRows();
>
> for (int index = first; index < (first + rows); index++) {
>
> // Position the table at the current row ...
>
> table.setRowIndex(index);
>
> // And get the message bean for this row ...
> MailBean mailBean = (MailBean)
> FacesContext.getCurrentInstance
> ().getRequestMap().get("mailBean");
>
> // If this row is selected, delete the corresponding message
> if
> (selected.isSelected()) {
> ...
> }
>
> }
> table.setRowIndex(-1);
> // We're done now
> return (null); // Redisplay the current page
> }
>
>
> Why does this work? Because there is a lot of mojo built in to the
> setRowIndex() method of the UIData component ... that is where the code that
> stores the bean for the current row into your "var" attribute lives. In
> addition, the UIData maintains a per-row value for all the input components,
> so that you don't have to. And, whenever you select a particular row index,
> it makes sure that the correct value for the current row is there.
>
> The "Repeater" component in the components demo that ships with the
> JavaServer Faces reference implementation (including source) has a more
> fleshed out example of this sort of thing, with a page that lets you add new
> rows, edit existing rows, and remove existing rows in a table ... plus the
> ability to scroll through a large list one page at a time. All of these
> techniques work the same with <h:data_table> as well.
>
> Craig McClanahan
> "
>
> And in RI Repeater example of
> http://jal.sun.com/services/jsf-components/index.jsp
> http://jal.sun.com/services/jsf-components/ShowSource.jsp?filename=/repeater.jsp:
> ...
> <%-- Visible checkbox for selection --%>
>
> <h:selectBooleanCheckbox
> id="checked"
> binding="#{RepeaterBean.checked}"/>
> ....
>
>
> http://jal.sun.com/services/jsf-components/ShowSource.jsp?filename=/src/demo/model/RepeaterBean.java
>
> /**
> * <p>The <code>checked</code> field for the current row.</p>
>
> */
> private UISelectBoolean checked = null;
>
>
> public UISelectBoolean getChecked() {
> return checked;
> }
>
>
> public void setChecked(UISelectBoolean checked) {
> this.checked
> = checked;
> }
> ...
> /**
> * <p>Clear the checked state for all customers.</p>
> */
> private void clear() {
>
> int n = count();
> for (int i = 0; i < n; i++) {
>
> data.setRowIndex(i);
> checked.setSelected(false);
> }
>
> }
> ...
>
>
> I can change my code, but still wondering is something broken because that
> was working in 1.1.1 but not in NB... and does that means that the RI
> example wouldn't work in Myfaces...
> --- VLi ---
>
>
>
>
> On 11/12/05, Yee CN <ye...@streamyx.com> wrote:
> > Is it possible/appropriate to use
> > <t:saveState value=#{SubscrierMB.dataModel}>
> >
> > to solve the problem?
> >
> > Regards,
> > Yee
> >
> > -----Original Message-----
> > From: Mathias Brökelmann [mailto: mbroekelmann@googlemail.com]
> > Sent: Saturday, 12 November 2005 9:38 PM
> > To: MyFaces Discussion
> > Subject: Re: Some notes of my loadtest results
> >
> > You have a component binding. I mean the valuebinding through the
> > attribute value. I expect something like this:
> >
> > <h:selectBooleanCheckbox
> > ...
> > value="#{SubscriberMB.checkedRow}"
> > ... >
> > </h:selectBooleanCheckbox>
> >
> > The problem is still the same. Datatable maintains internal rowstates
> > which contains the setted values for each component and each row but
> > they are discared before render phase. The invoke application phase in
> > which you set the boolean value is before the render phase. Any value
> > you have set in the application phase through the component binding
> > will be lost since updateModel phase (which could set the value
> > through the value binding) is before invoke application.
> >
> >
> > 2005/11/12, Vesa Lindfors <ve...@gmail.com>:
> > > Sorry, I wasn't clear enough in problem description - sure I have
> > > valuebinding in each row:
> > > <h:selectBooleanCheckbox
> > > ...
> > > binding="#{SubscriberMB.checkedRow}"
> > > ... >
> > > </h:selectBooleanCheckbox>
> > > and that is working like earlier. I can select (one by one) and have
> > actions
> > > for selected users (selected by clicking checkboxes).
> > >
> > > On the other words, I failed to set checkboxes in table by programming
> > >
> > > dataModel.setRowIndex(index);
> > > checkedRow.setSelected(true);
> > >
> > > And I think that should work also?
> > > -- vLi --
> > >
> > >
> > >
> > > On 11/12/05, Mathias Brökelmann < mbroekelmann@googlemail.com> wrote:
> > > > I wonder that this is working in 1.1.1.
> > > >
> > > > Normally the state for each row in a datatable is discarded before the
> > > > table is rendered if the page data contains no error. Any input
> > > > component without a valuebinding loses its value. I suggest you to use
> > > > a valuebinding for the UISelectBoolean field. This will work better in
> > > > datatables. If the selectall button is executed set the flags for the
> > > > managed bean field for each row which was bound to the select boolean
> > > > component.
> > > >
> > > > 2005/11/11, Vesa Lindfors <vesa.lindfors@gmail.com >:
> > > > > I have just one more issue before I can test NB again with
> > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
> > > > >
> > > > > I had earlier ( 1.1.1) working "Select all" function for checkboxs
> in
> > my
> > > > > datatable, now in NB it's not (neither in cleint or server side). Is
> > > there
> > > > > any thing I should make differently?
> > > > >
> > > > > private UISelectBoolean checkedRow = null;
> > > > >
> > > > > public UISelectBoolean getCheckedRow() { return checkedRow; }
> > > > >
> > > > > public void setCheckedRow(UISelectBoolean checked) {
> this.checkedRow
> > =
> > > > > checked; }
> > > > >
> > > > > public void selectAllListener(ActionEvent event) {
> > > > > ...
> > > > > for (int index = first; index < rows; index++) {
> > > > > dataModel.setRowIndex(index);
> > > > > checkedRow.setSelected(true);
> > > > > }
> > > > > }
> > > > > ...
> > > > > }
> > > > >
> > > > > x:dataTable has preserveDataModel="false" and the data list stored
> by
> > > > > x:saveState.
> > > > >
> > > > > I can see that method is called properly and no exception is shown,
> > but
> > > the
> > > > > checkboxes are not marked as earlier...
> > > > >
> > > > > -- VLi ---
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11/9/05, Mathias Brökelmann < mbroekelmann@googlemail.com >
> wrote:
> > > > > > You are right latest commit breaks that. I have committed a fix
> for
> > > > > > that so it is working now.
> > > > > >
> > > > > > 2005/11/9, Vesa Lindfors < vesa.lindfors@gmail.com>:
> > > > > > > Mathias,
> > > > > > > I tested successfully the rest of platforms with
> > > > > > > javax.faces.STATE_SAVING_METHOD=server &&
> > > > > > > SERIALIZE_STATE_IN_SESSION=false &&
> > > myfaces-20051030 .
> > > > > > >
> > > > > > > Now I should have time to continue testing your suggestion:
> > > > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
> > > > > > > myfaces-20051103.
> > > > > > > But now my testing fails at the very begin: the application
> > didn't
> > > > > worked
> > > > > > > at all with state saving "server" - my ActionEvents weren't
> fired
> > at
> > > all
> > > > > ( I
> > > > > > > mean very basic form buttons didn't work anymore). Turning state
> > > saving
> > > > > to
> > > > > > > the "client" it start to work again. I tried also with
> > > myfaces-20051107
> > > > > and
> > > > > > > same results. Do you have any idea what could be changed in NB
> > > during
> > > > > > > 20051030- 20051103 so that it can have such effect?
> > > > > > >
> > > > > > > --- VLi ---
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >One more thing. I have removed the gzipping of the serialized
> > > stream
> > > > > > > > >if server side state is used. This might have caused some
> > > additional
> > > > > > > > >performance problems. Would it be possible to take the next
> > > nightly
> > > > > > > > >(20051103) and test it again with
> > > > > > > >
> > > >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true
> > > > > to
> > > > > > > check this?
> > > > > > > >
> > > > > > > > >Mathias
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mathias
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Mathias
> > > >
> > >
> > >
> >
> >
> > --
> > Mathias
> >
> >
>
>
--
Mathias
Re: Some notes of my loadtest results
Posted by Vesa Lindfors <ve...@gmail.com>.
Ok, what I'm doing is something Craig McClanahan has shown in
http://forum.java.sun.com/thread.jspa?threadID=486654&messageID=2819434:
"...
The UIData control will take care of making sure that the correct MailBean
is stored in the "var" element for each row. In the delete() method, you can
simply walk through your list of MailBean beans and take action on the ones
that have the "selected" property set.
If you do not have a boolean property on the bean that you can use, Approach
(2) is to bind your component directly into your backing bean ... something
like this:
<h:form id="mailbox">
<h:data_table value="#{mailsForm.mails}" var="mailBean"
binding="#{mybean.table}">
<h:column>
<f:facet>
<h:output_text value="Selected"/>
</f:facet>
<h:selectboolean_checkbox id="selected" binding="#{mybean.selected}"/>
</h:column>
<h:column>
<f:facet>
<h:output_text value="From"/>
</f:facet>
<h:output_text id="from" value="#{mailBean.from}"/>
</h:column>
...
</h:data_table>
<h:command_button id="delete" action="#{mybean.delete}"/>
</h:form>
with a backing bean something like this:
*public* *class* MyBean {
// Property bound to the "selected" checkbox
UISelectBoolean selected;
*public* UISelectBoolean getSelected() {
*return* selected;
}
*public* *void* setSelected(UISelectBoolean selected) {
this.selected = selected;
}
// Property bound to the entire table
UIData table;
*public* UIData getTable() {
*return* table;
}
*public* *void* setTable(UIData table) {
this.table = table;
}
// Method to delete all the selected messages
*public* String delete() {
// Iterate through the data rows ...
*int* first = table.getFirst();
*int* rows = table.getRows();
*for* (*int* index = first; index < (first + rows); index++) {
// Position the table at the current row ...
table.setRowIndex(index);
// And get the message bean for this row ...
MailBean mailBean = (MailBean)
FacesContext.getCurrentInstance().getRequestMap().get("mailBean");
// If this row is selected, delete the corresponding message
*if* (selected.isSelected()) {
...
}
}
table.setRowIndex(-1); // We're done now
*return* (*null*); // Redisplay the current page
}
Why does this work? Because there is a lot of mojo built in to the
setRowIndex() method of the UIData component ... that is where the code that
stores the bean for the current row into your "var" attribute lives. In
addition, the UIData maintains a per-row value for all the input components,
so that you don't have to. And, whenever you select a particular row index,
it makes sure that the correct value for the current row is there.
The "Repeater" component in the components demo that ships with the
JavaServer Faces reference implementation (including source) has a more
fleshed out example of this sort of thing, with a page that lets you add new
rows, edit existing rows, and remove existing rows in a table ... plus the
ability to scroll through a large list one page at a time. All of these
techniques work the same with <h:data_table> as well.
Craig McClanahan
"
And in RI Repeater example of
http://jal.sun.com/services/jsf-components/index.jsp
http://jal.sun.com/services/jsf-components/ShowSource.jsp?filename=/repeater.jsp:
...
<%-- Visible checkbox for selection --%>
<h:selectBooleanCheckbox
id="checked"
binding="#{RepeaterBean.checked}"/>
....
http://jal.sun.com/services/jsf-components/ShowSource.jsp?filename=/src/demo/model/RepeaterBean.java
/**
* <p>The <code>checked</code> field for the current row.</p>
*/
private UISelectBoolean checked = null;
public UISelectBoolean getChecked() {
return checked;
}
public void setChecked(UISelectBoolean checked) {
this.checked = checked;
}
...
/**
* <p>Clear the checked state for all customers.</p>
*/
private void clear() {
int n = count();
for (int i = 0; i < n; i++) {
data.setRowIndex(i);
checked.setSelected(false);
}
}
...
I can change my code, but still wondering is something broken because that
was working in 1.1.1 but not in NB... and does that means that the RI
example wouldn't work in Myfaces...
--- VLi ---
On 11/12/05, Yee CN <ye...@streamyx.com> wrote:
>
> Is it possible/appropriate to use
> <t:saveState value=#{SubscrierMB.dataModel}>
>
> to solve the problem?
>
> Regards,
> Yee
>
> -----Original Message-----
> From: Mathias Brökelmann [mailto:mbroekelmann@googlemail.com]
> Sent: Saturday, 12 November 2005 9:38 PM
> To: MyFaces Discussion
> Subject: Re: Some notes of my loadtest results
>
> You have a component binding. I mean the valuebinding through the
> attribute value. I expect something like this:
>
> <h:selectBooleanCheckbox
> ...
> value="#{SubscriberMB.checkedRow}"
> ... >
> </h:selectBooleanCheckbox>
>
> The problem is still the same. Datatable maintains internal rowstates
> which contains the setted values for each component and each row but
> they are discared before render phase. The invoke application phase in
> which you set the boolean value is before the render phase. Any value
> you have set in the application phase through the component binding
> will be lost since updateModel phase (which could set the value
> through the value binding) is before invoke application.
>
>
> 2005/11/12, Vesa Lindfors <ve...@gmail.com>:
> > Sorry, I wasn't clear enough in problem description - sure I have
> > valuebinding in each row:
> > <h:selectBooleanCheckbox
> > ...
> > binding="#{SubscriberMB.checkedRow}"
> > ... >
> > </h:selectBooleanCheckbox>
> > and that is working like earlier. I can select (one by one) and have
> actions
> > for selected users (selected by clicking checkboxes).
> >
> > On the other words, I failed to set checkboxes in table by programming
> >
> > dataModel.setRowIndex(index);
> > checkedRow.setSelected(true);
> >
> > And I think that should work also?
> > -- vLi --
> >
> >
> >
> > On 11/12/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > > I wonder that this is working in 1.1.1.
> > >
> > > Normally the state for each row in a datatable is discarded before the
> > > table is rendered if the page data contains no error. Any input
> > > component without a valuebinding loses its value. I suggest you to use
> > > a valuebinding for the UISelectBoolean field. This will work better in
> > > datatables. If the selectall button is executed set the flags for the
> > > managed bean field for each row which was bound to the select boolean
> > > component.
> > >
> > > 2005/11/11, Vesa Lindfors <ve...@gmail.com>:
> > > > I have just one more issue before I can test NB again with
> > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
> > > >
> > > > I had earlier (1.1.1) working "Select all" function for checkboxs in
> my
> > > > datatable, now in NB it's not (neither in cleint or server side). Is
> > there
> > > > any thing I should make differently?
> > > >
> > > > private UISelectBoolean checkedRow = null;
> > > >
> > > > public UISelectBoolean getCheckedRow() { return checkedRow; }
> > > >
> > > > public void setCheckedRow(UISelectBoolean checked) { this.checkedRow
> =
> > > > checked; }
> > > >
> > > > public void selectAllListener(ActionEvent event) {
> > > > ...
> > > > for (int index = first; index < rows; index++) {
> > > > dataModel.setRowIndex(index);
> > > > checkedRow.setSelected(true);
> > > > }
> > > > }
> > > > ...
> > > > }
> > > >
> > > > x:dataTable has preserveDataModel="false" and the data list stored
> by
> > > > x:saveState.
> > > >
> > > > I can see that method is called properly and no exception is shown,
> but
> > the
> > > > checkboxes are not marked as earlier...
> > > >
> > > > -- VLi ---
> > > >
> > > >
> > > >
> > > >
> > > > On 11/9/05, Mathias Brökelmann <mbroekelmann@googlemail.com > wrote:
> > > > > You are right latest commit breaks that. I have committed a fix
> for
> > > > > that so it is working now.
> > > > >
> > > > > 2005/11/9, Vesa Lindfors < vesa.lindfors@gmail.com>:
> > > > > > Mathias,
> > > > > > I tested successfully the rest of platforms with
> > > > > > javax.faces.STATE_SAVING_METHOD=server &&
> > > > > > SERIALIZE_STATE_IN_SESSION=false &&
> > myfaces-20051030 .
> > > > > >
> > > > > > Now I should have time to continue testing your suggestion:
> > > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
> > > > > > myfaces-20051103.
> > > > > > But now my testing fails at the very begin: the application
> didn't
> > > > worked
> > > > > > at all with state saving "server" - my ActionEvents weren't
> fired
> at
> > all
> > > > ( I
> > > > > > mean very basic form buttons didn't work anymore). Turning state
> > saving
> > > > to
> > > > > > the "client" it start to work again. I tried also with
> > myfaces-20051107
> > > > and
> > > > > > same results. Do you have any idea what could be changed in NB
> > during
> > > > > > 20051030- 20051103 so that it can have such effect?
> > > > > >
> > > > > > --- VLi ---
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >One more thing. I have removed the gzipping of the serialized
> > stream
> > > > > > > >if server side state is used. This might have caused some
> > additional
> > > > > > > >performance problems. Would it be possible to take the next
> > nightly
> > > > > > > >(20051103) and test it again with
> > > > > > >
> > >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true
> > > > to
> > > > > > check this?
> > > > > > >
> > > > > > > >Mathias
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Mathias
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Mathias
> > >
> >
> >
>
>
> --
> Mathias
>
>
RE: Some notes of my loadtest results
Posted by Yee CN <ye...@streamyx.com>.
Is it possible/appropriate to use
<t:saveState value=#{SubscrierMB.dataModel}>
to solve the problem?
Regards,
Yee
-----Original Message-----
From: Mathias Brökelmann [mailto:mbroekelmann@googlemail.com]
Sent: Saturday, 12 November 2005 9:38 PM
To: MyFaces Discussion
Subject: Re: Some notes of my loadtest results
You have a component binding. I mean the valuebinding through the
attribute value. I expect something like this:
<h:selectBooleanCheckbox
...
value="#{SubscriberMB.checkedRow}"
... >
</h:selectBooleanCheckbox>
The problem is still the same. Datatable maintains internal rowstates
which contains the setted values for each component and each row but
they are discared before render phase. The invoke application phase in
which you set the boolean value is before the render phase. Any value
you have set in the application phase through the component binding
will be lost since updateModel phase (which could set the value
through the value binding) is before invoke application.
2005/11/12, Vesa Lindfors <ve...@gmail.com>:
> Sorry, I wasn't clear enough in problem description - sure I have
> valuebinding in each row:
> <h:selectBooleanCheckbox
> ...
> binding="#{SubscriberMB.checkedRow}"
> ... >
> </h:selectBooleanCheckbox>
> and that is working like earlier. I can select (one by one) and have
actions
> for selected users (selected by clicking checkboxes).
>
> On the other words, I failed to set checkboxes in table by programming
>
> dataModel.setRowIndex(index);
> checkedRow.setSelected(true);
>
> And I think that should work also?
> -- vLi --
>
>
>
> On 11/12/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > I wonder that this is working in 1.1.1.
> >
> > Normally the state for each row in a datatable is discarded before the
> > table is rendered if the page data contains no error. Any input
> > component without a valuebinding loses its value. I suggest you to use
> > a valuebinding for the UISelectBoolean field. This will work better in
> > datatables. If the selectall button is executed set the flags for the
> > managed bean field for each row which was bound to the select boolean
> > component.
> >
> > 2005/11/11, Vesa Lindfors <ve...@gmail.com>:
> > > I have just one more issue before I can test NB again with
> > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
> > >
> > > I had earlier (1.1.1) working "Select all" function for checkboxs in
my
> > > datatable, now in NB it's not (neither in cleint or server side). Is
> there
> > > any thing I should make differently?
> > >
> > > private UISelectBoolean checkedRow = null;
> > >
> > > public UISelectBoolean getCheckedRow() { return checkedRow; }
> > >
> > > public void setCheckedRow(UISelectBoolean checked) { this.checkedRow
=
> > > checked; }
> > >
> > > public void selectAllListener(ActionEvent event) {
> > > ...
> > > for (int index = first; index < rows; index++) {
> > > dataModel.setRowIndex(index);
> > > checkedRow.setSelected(true);
> > > }
> > > }
> > > ...
> > > }
> > >
> > > x:dataTable has preserveDataModel="false" and the data list stored by
> > > x:saveState.
> > >
> > > I can see that method is called properly and no exception is shown,
but
> the
> > > checkboxes are not marked as earlier...
> > >
> > > -- VLi ---
> > >
> > >
> > >
> > >
> > > On 11/9/05, Mathias Brökelmann <mbroekelmann@googlemail.com > wrote:
> > > > You are right latest commit breaks that. I have committed a fix for
> > > > that so it is working now.
> > > >
> > > > 2005/11/9, Vesa Lindfors < vesa.lindfors@gmail.com>:
> > > > > Mathias,
> > > > > I tested successfully the rest of platforms with
> > > > > javax.faces.STATE_SAVING_METHOD=server &&
> > > > > SERIALIZE_STATE_IN_SESSION=false &&
> myfaces-20051030 .
> > > > >
> > > > > Now I should have time to continue testing your suggestion:
> > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
> > > > > myfaces-20051103.
> > > > > But now my testing fails at the very begin: the application
didn't
> > > worked
> > > > > at all with state saving "server" - my ActionEvents weren't fired
at
> all
> > > ( I
> > > > > mean very basic form buttons didn't work anymore). Turning state
> saving
> > > to
> > > > > the "client" it start to work again. I tried also with
> myfaces-20051107
> > > and
> > > > > same results. Do you have any idea what could be changed in NB
> during
> > > > > 20051030- 20051103 so that it can have such effect?
> > > > >
> > > > > --- VLi ---
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >One more thing. I have removed the gzipping of the serialized
> stream
> > > > > > >if server side state is used. This might have caused some
> additional
> > > > > > >performance problems. Would it be possible to take the next
> nightly
> > > > > > >(20051103) and test it again with
> > > > > >
> >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true
> > > to
> > > > > check this?
> > > > > >
> > > > > > >Mathias
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Mathias
> > > >
> > >
> > >
> >
> >
> > --
> > Mathias
> >
>
>
--
Mathias
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
You have a component binding. I mean the valuebinding through the
attribute value. I expect something like this:
<h:selectBooleanCheckbox
...
value="#{SubscriberMB.checkedRow}"
... >
</h:selectBooleanCheckbox>
The problem is still the same. Datatable maintains internal rowstates
which contains the setted values for each component and each row but
they are discared before render phase. The invoke application phase in
which you set the boolean value is before the render phase. Any value
you have set in the application phase through the component binding
will be lost since updateModel phase (which could set the value
through the value binding) is before invoke application.
2005/11/12, Vesa Lindfors <ve...@gmail.com>:
> Sorry, I wasn't clear enough in problem description - sure I have
> valuebinding in each row:
> <h:selectBooleanCheckbox
> ...
> binding="#{SubscriberMB.checkedRow}"
> ... >
> </h:selectBooleanCheckbox>
> and that is working like earlier. I can select (one by one) and have actions
> for selected users (selected by clicking checkboxes).
>
> On the other words, I failed to set checkboxes in table by programming
>
> dataModel.setRowIndex(index);
> checkedRow.setSelected(true);
>
> And I think that should work also?
> -- vLi --
>
>
>
> On 11/12/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > I wonder that this is working in 1.1.1.
> >
> > Normally the state for each row in a datatable is discarded before the
> > table is rendered if the page data contains no error. Any input
> > component without a valuebinding loses its value. I suggest you to use
> > a valuebinding for the UISelectBoolean field. This will work better in
> > datatables. If the selectall button is executed set the flags for the
> > managed bean field for each row which was bound to the select boolean
> > component.
> >
> > 2005/11/11, Vesa Lindfors <ve...@gmail.com>:
> > > I have just one more issue before I can test NB again with
> > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
> > >
> > > I had earlier (1.1.1) working "Select all" function for checkboxs in my
> > > datatable, now in NB it's not (neither in cleint or server side). Is
> there
> > > any thing I should make differently?
> > >
> > > private UISelectBoolean checkedRow = null;
> > >
> > > public UISelectBoolean getCheckedRow() { return checkedRow; }
> > >
> > > public void setCheckedRow(UISelectBoolean checked) { this.checkedRow =
> > > checked; }
> > >
> > > public void selectAllListener(ActionEvent event) {
> > > ...
> > > for (int index = first; index < rows; index++) {
> > > dataModel.setRowIndex(index);
> > > checkedRow.setSelected(true);
> > > }
> > > }
> > > ...
> > > }
> > >
> > > x:dataTable has preserveDataModel="false" and the data list stored by
> > > x:saveState.
> > >
> > > I can see that method is called properly and no exception is shown, but
> the
> > > checkboxes are not marked as earlier...
> > >
> > > -- VLi ---
> > >
> > >
> > >
> > >
> > > On 11/9/05, Mathias Brökelmann <mbroekelmann@googlemail.com > wrote:
> > > > You are right latest commit breaks that. I have committed a fix for
> > > > that so it is working now.
> > > >
> > > > 2005/11/9, Vesa Lindfors < vesa.lindfors@gmail.com>:
> > > > > Mathias,
> > > > > I tested successfully the rest of platforms with
> > > > > javax.faces.STATE_SAVING_METHOD=server &&
> > > > > SERIALIZE_STATE_IN_SESSION=false &&
> myfaces-20051030 .
> > > > >
> > > > > Now I should have time to continue testing your suggestion:
> > > > > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
> > > > > myfaces-20051103.
> > > > > But now my testing fails at the very begin: the application didn't
> > > worked
> > > > > at all with state saving "server" - my ActionEvents weren't fired at
> all
> > > ( I
> > > > > mean very basic form buttons didn't work anymore). Turning state
> saving
> > > to
> > > > > the "client" it start to work again. I tried also with
> myfaces-20051107
> > > and
> > > > > same results. Do you have any idea what could be changed in NB
> during
> > > > > 20051030- 20051103 so that it can have such effect?
> > > > >
> > > > > --- VLi ---
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >One more thing. I have removed the gzipping of the serialized
> stream
> > > > > > >if server side state is used. This might have caused some
> additional
> > > > > > >performance problems. Would it be possible to take the next
> nightly
> > > > > > >(20051103) and test it again with
> > > > > >
> >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true
> > > to
> > > > > check this?
> > > > > >
> > > > > > >Mathias
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Mathias
> > > >
> > >
> > >
> >
> >
> > --
> > Mathias
> >
>
>
--
Mathias
Re: Some notes of my loadtest results
Posted by Vesa Lindfors <ve...@gmail.com>.
I have just one more issue before I can test NB again with
STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true
I had earlier (1.1.1) working "Select all" function for checkboxs in my
datatable, now in NB it's not (neither in cleint or server side). Is there
any thing I should make differently?
private UISelectBoolean checkedRow = null;
public UISelectBoolean getCheckedRow() { return checkedRow; }
public void setCheckedRow(UISelectBoolean checked) { this.checkedRow =
checked; }
public void selectAllListener(ActionEvent event) {
...
for (int index = first; index < rows; index++) {
dataModel.setRowIndex(index);
checkedRow.setSelected(true);
}
}
...
}
x:dataTable has preserveDataModel="false" and the data list stored by
x:saveState.
I can see that method is called properly and no exception is shown, but the
checkboxes are not marked as earlier...
-- VLi ---
On 11/9/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
>
> You are right latest commit breaks that. I have committed a fix for
> that so it is working now.
>
> 2005/11/9, Vesa Lindfors <ve...@gmail.com>:
> > Mathias,
> > I tested successfully the rest of platforms with
> > javax.faces.STATE_SAVING_METHOD=server &&
> > SERIALIZE_STATE_IN_SESSION=false && myfaces-20051030 .
> >
> > Now I should have time to continue testing your suggestion:
> > STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
> > myfaces-20051103.
> > But now my testing fails at the very begin: the application didn't
> worked
> > at all with state saving "server" - my ActionEvents weren't fired at all
> ( I
> > mean very basic form buttons didn't work anymore). Turning state saving
> to
> > the "client" it start to work again. I tried also with myfaces-20051107
> and
> > same results. Do you have any idea what could be changed in NB during
> > 20051030- 20051103 so that it can have such effect?
> >
> > --- VLi ---
> >
> >
> > >
> > >
> > > >One more thing. I have removed the gzipping of the serialized stream
> > > >if server side state is used. This might have caused some additional
> > > >performance problems. Would it be possible to take the next nightly
> > > >(20051103) and test it again with
> > > >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true to
> > check this?
> > >
> > > >Mathias
> > >
> >
> >
>
>
> --
> Mathias
>
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
You are right latest commit breaks that. I have committed a fix for
that so it is working now.
2005/11/9, Vesa Lindfors <ve...@gmail.com>:
> Mathias,
> I tested successfully the rest of platforms with
> javax.faces.STATE_SAVING_METHOD=server &&
> SERIALIZE_STATE_IN_SESSION=false && myfaces-20051030 .
>
> Now I should have time to continue testing your suggestion:
> STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
> myfaces-20051103.
> But now my testing fails at the very begin: the application didn't worked
> at all with state saving "server" - my ActionEvents weren't fired at all ( I
> mean very basic form buttons didn't work anymore). Turning state saving to
> the "client" it start to work again. I tried also with myfaces-20051107 and
> same results. Do you have any idea what could be changed in NB during
> 20051030- 20051103 so that it can have such effect?
>
> --- VLi ---
>
>
> >
> >
> > >One more thing. I have removed the gzipping of the serialized stream
> > >if server side state is used. This might have caused some additional
> > >performance problems. Would it be possible to take the next nightly
> > >(20051103) and test it again with
> > >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true to
> check this?
> >
> > >Mathias
> >
>
>
--
Mathias
Re: Some notes of my loadtest results
Posted by Vesa Lindfors <ve...@gmail.com>.
Mathias,
I tested successfully the rest of platforms with
javax.faces.STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=false
&& myfaces-20051030.
Now I should have time to continue testing your suggestion:
STATE_SAVING_METHOD=server && SERIALIZE_STATE_IN_SESSION=true &&
myfaces-20051103.
But now my testing fails at the very begin: the application didn't worked at
all with state saving "server" - my ActionEvents weren't fired at all ( I
mean very basic form buttons didn't work anymore). Turning state saving to
the "client" it start to work again. I tried also with myfaces-20051107 and
same results. Do you have any idea what could be changed in NB during
20051030-20051103 so that it can have such effect?
--- VLi ---
>
> >One more thing. I have removed the gzipping of the serialized stream
> >if server side state is used. This might have caused some additional
> >performance problems. Would it be possible to take the next nightly
> >(20051103) and test it again with
> >org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true to check this?
>
> >Mathias
>
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
AFAIK only t:savestate may be an issue if you use a bean which
maintains a state for a view. this state would be shared among the
views if a user opens a new browser window. If the state of this bean
is changed for one window it will also change (same state) for the
other window which still has the old state. The next request for the
window will probably fail because the state of the bean has been
changed in meantime.
But I think there is a solution for this problem. Your bean could
provide a getter method which returns an object with the state (like
an object array containing the field values of the bean):
public Object getState()
{
Object[] state = new Object[2];
state[0] = field1;
state[1] = field2;
return state;
}
and a setter method which writes the state back to the bean:
public void setState(Object value)
{
Object[] state = (Object[])value;
field1 = state[0];
field2 = state[1];
}
you can then use <t:savestate value="#{bean.state}"/> in your view. Of
course if your fields are mutable objects you have to make sure either
these objects are never modified or you save the state of these
objects too.
This will probably the most effective way since serializing through
ObjectOutputStream/ObjectInputStream is definitely a performance
killer.
One more thing. I have removed the gzipping of the serialized stream
if server side state is used. This might have caused some additional
performance problems. Would it be possible to take the next nightly
(20051103) and test it again with
org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true to check this?
> 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 ?
--
Mathias
Re: Some notes of my loadtest results
Posted by Vesa Lindfors <ve...@gmail.com>.
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 <mb...@googlemail.com> 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 <ve...@gmail.com>:
> >
> >
> > 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
>
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
@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 <ve...@gmail.com>:
>
>
> 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
Re: Some notes of my loadtest results
Posted by Martin Marinschek <ma...@gmail.com>.
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 <mb...@googlemail.com> 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 <tr...@gmail.com>:
> > 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 <mb...@googlemail.com> 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 <ve...@gmail.com>:
> > > >
> > > >
> > > > 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
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
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 <tr...@gmail.com>:
> 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 <mb...@googlemail.com> 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 <ve...@gmail.com>:
> > >
> > >
> > > 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
Re: Some notes of my loadtest results
Posted by Travis Reeder <tr...@gmail.com>.
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 <mb...@googlemail.com> 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 <ve...@gmail.com>:
> >
> >
> > 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
>
Re: Some notes of my loadtest results
Posted by Mathias Brökelmann <mb...@googlemail.com>.
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 <ve...@gmail.com>:
>
>
> 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