Re: Some notes of my loadtest results
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 <[EMAIL PROTECTED]> wrote:
Using t:savestate is not the solution.t:savestate holds the state between requests. The rowstates maintainedby UIData are only created and used while processing the lifecycle ofjsf. They are discarded at the end of each request.
2005/11/12, Yee CN <[EMAIL PROTECTED]>:> Is it possible/appropriate to use> >> to solve the problem?
>> Regards,> Yee>> -Original Message-> From: Mathias Brökelmann [mailto:[EMAIL PROTECTED]]> 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:
>> > ...> value="#{SubscriberMB.checkedRow}"> ... >>
>> 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 <[EMAIL PROTECTED]>:> > Sorry, I wasn't clear enough in problem description - sure I have
> > valuebinding in each row:> >> > ...> > binding="#{SubscriberMB.checkedRow}"> > ... >
> >> > 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 <[EMAIL PROTECTED]
> 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 <
[EMAIL PROTECTED]>:> > > > 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 <
[EMAIL PROTECTED] > wrote:> > > > > You are right latest commit breaks that. I have committed a fix for> > > > > that so it is working no
Re: Some notes of my loadtest results
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 <[EMAIL PROTECTED]>:
> Is it possible/appropriate to use
>
>
> to solve the problem?
>
> Regards,
> Yee
>
> -Original Message-
> From: Mathias Brökelmann [mailto:[EMAIL PROTECTED]
> 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:
>
> ...
> value="#{SubscriberMB.checkedRow}"
> ... >
>
>
> 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 <[EMAIL PROTECTED]>:
> > Sorry, I wasn't clear enough in problem description - sure I have
> > valuebinding in each row:
> > > ...
> > binding="#{SubscriberMB.checkedRow}"
> > ... >
> >
> > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > > > 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]>:
> >
Re: Some notes of my loadtest results
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 <[EMAIL PROTECTED]>:
> 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:
>
> "#{mybean.table}">
>
>
>
>
> "selected" binding="#{mybean.selected}"/>
>
>
>
> "From"/>
>
>
>
>
> ...
>
>
>
>
>
> 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 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 --%>
>
>id="checked"
> binding="#{RepeaterBean.checked}"/>
>
>
>
> http://jal.sun.com/services/jsf-components/ShowSource.jsp?filename=/src/demo/model/RepeaterBean.java
>
> /**
> * The checked field for the current row.
>
> */
> private UISelectBoolean checked = null;
>
>
> public UISelectBoolean getChecked() {
> return checked;
> }
>
>
> public void setChecked(UISelectBoolean checked) {
> this.checked
> = checked;
> }
> ...
> /**
> * Clear the checked state for all customers.
> */
> 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 mea
Re: Some notes of my loadtest results
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:
"mailbox"> "#{mailsForm.mails}" var="mailBean" binding=
"#{mybean.table}">"Selected"/>"selected" binding="#{mybean.selected}"/>"From"/>"from" value="#{mailBean.from}"/>
..."delete" action="" color="red">"#{mybean.delete}"/>
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 tableUIData table;public UIData getTable() {
return table;}public void setTable(UIData table) { this.table = table;
} // Method to delete all the selected messagespublic 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 messageif
(selected.isSelected()) {...} }table.setRowIndex(-1);
// We're done nowreturn (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 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 --%>
id="checked" binding="#{RepeaterBean.checked}"/>
http://jal.sun.com/services/jsf-components/ShowSource.jsp?filename=/src/demo/model/RepeaterBean.java /** * The checked field for the current row.
*/private UISelectBoolean checked = null;public UISelectBoolean getChecked() {return checked;}public void setChecked(UISelectBoolean checked) {this.checked
= checked;}.../** * Clear the checked state for all customers. */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 <[EMAIL PROTECTED]> wrote:
Is it possible/appropriate to useto solve the problem?Regards,Yee-Original Message-From: Mathias Brökelmann [mailto:
[EMAIL PROTECTED]]Sent: Saturday, 12 November 2005 9:38 PMTo: MyFaces DiscussionSubject: Re: Some notes of my loadtest resultsYou have a component binding. I mean the valuebinding through the
attribute value. I expect something like this: ... value="#{SubscriberMB.checkedRow}" ... >
The problem is still the same. Datatable maintains internal rowstateswhich contains the setted values for each component and each row butthey are discared before render phase. The invoke application phase in
which you set the boolean value is before the render phase. Any valueyou have set in the application phase through the component bindingwill be l
RE: Some notes of my loadtest results
Is it possible/appropriate to use
to solve the problem?
Regards,
Yee
-Original Message-
From: Mathias Brökelmann [mailto:[EMAIL PROTECTED]
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:
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 <[EMAIL PROTECTED]>:
> Sorry, I wasn't clear enough in problem description - sure I have
> valuebinding in each row:
> ...
> binding="#{SubscriberMB.checkedRow}"
> ... >
>
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > > 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]>:
> > > > > 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
&
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:
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 <[EMAIL PROTECTED]>:
> Sorry, I wasn't clear enough in problem description - sure I have
> valuebinding in each row:
> ...
> binding="#{SubscriberMB.checkedRow}"
> ... >
>
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > > 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]>:
> > > > > 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
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 <[EMAIL PROTECTED]> wrote:
You are right latest commit breaks that. I have committed a fix forthat so it is working now.2005/11/9, Vesa Lindfors <[EMAIL PROTECTED]>:> 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
You are right latest commit breaks that. I have committed a fix for that so it is working now. 2005/11/9, Vesa Lindfors <[EMAIL PROTECTED]>: > 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
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
comments inline... > > 1. We can now use STATE_SAVING_METHOD=server, and the back-button > > (and pop-up windows) will work correctly (e.g., when my pop-up > > window closes, my base window won't have forgotten its state)? yes you can do this now > > 2. Using STATE_SAVING_METHOD=server is faster and thus recommended? definitely. Since the state must not be transferred to the client which saves time. > > > > Just wondering what the current state of affairs is regarding the > > tradeoffs between server and client state saving method. > > +1 for this question..:) I have gone back and forth between the two and now > am not at all sure which is recommended under what circumstances and why. I > would also like to know, if MyFaces 1.1.1 is "good enough" or the answer > given, whatver it may be, pertains to the latest nightly builds. only nightly builds supports multiple views if server state is used. -- Mathias
RE: Some notes of my loadtest results
"CONNER, BRENDAN \(SBCSI\)" <[EMAIL PROTECTED]> wrote on 11/04/2005 10:16:25 AM: > The app I'm working on is currently using > STATE_SAVING_METHOD=client, because, at the time our code was > written, that was the only way to handle the back-button (and pop-up > windows) correctly. Can I assume from some of the notes that have > been passed around that: > > 1. We can now use STATE_SAVING_METHOD=server, and the back-button > (and pop-up windows) will work correctly (e.g., when my pop-up > window closes, my base window won't have forgotten its state)? > 2. Using STATE_SAVING_METHOD=server is faster and thus recommended? > > Just wondering what the current state of affairs is regarding the > tradeoffs between server and client state saving method. +1 for this question..:) I have gone back and forth between the two and now am not at all sure which is recommended under what circumstances and why. I would also like to know, if MyFaces 1.1.1 is "good enough" or the answer given, whatver it may be, pertains to the latest nightly builds. > > - Brendan thanks, Geeta
RE: Some notes of my loadtest results
The app I'm working on is currently using STATE_SAVING_METHOD=client, because, at the time our code was written, that was the only way to handle the back-button (and pop-up windows) correctly. Can I assume from some of the notes that have been passed around that: 1. We can now use STATE_SAVING_METHOD=server, and the back-button (and pop-up windows) will work correctly (e.g., when my pop-up window closes, my base window won't have forgotten its state)? 2. Using STATE_SAVING_METHOD=server is faster and thus recommended? Just wondering what the current state of affairs is regarding the tradeoffs between server and client state saving method. - Brendan -Original Message- From: Mathias Brökelmann [mailto:[EMAIL PROTECTED] Sent: Friday, November 04, 2005 2:18 AM To: MyFaces Discussion Subject: Re: Some notes of my loadtest results If this setting is set to false the user might have some strange effects if multiple browser windows are used. IMO functionality is more important than performance which is the reason to have true as the default value. 2005/11/3, Travis Reeder <[EMAIL PROTECTED]>: > Shouldn't it default to SERIALIZE_STATE_IN_SESSION = false if it's > such a performance killer? > > Travis > > On 11/3/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > > SERIALIZE_STATE_IN_SESSION and NUMBER_OF_VIEWS_IN_SESSION are only > > effective if STATE_SAVING_METHOD=server otherwise it´s settings will > > be ignored. > > > > The default for SERIALIZE_STATE_IN_SESSION is true and > > NUMBER_OF_VIEWS_IN_SESSION is 20 and are recommended if you use > > STATE_SAVING_METHOD=server to avoid strange side effects. > > > > 2005/11/3, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]>: > > > > > > So is there enough information at the moment to make a recommendation > > > about > > > how to set the parameters? For example: > > > > > > 1. If I set STATE_SAVING_METHOD=client, should I then set > > > SERIALIZE_STATE_IN_SESSION=false? > > > > > > 2. If I set STATE_SAVING_METHOD=server, should I then set > > > SERIALIZE_STATE_IN_SESSION=true? > > > > > > - Brendan > > > > > > -Original Message- > > > From: Vesa Lindfors [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 03, 2005 1:51 AM > > > Cc: MyFaces Discussion > > > Subject: Re: Some notes of my loadtest results > > > > > > > > > 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 <[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
Re: Some notes of my loadtest results
If this setting is set to false the user might have some strange effects if multiple browser windows are used. IMO functionality is more important than performance which is the reason to have true as the default value. 2005/11/3, Travis Reeder <[EMAIL PROTECTED]>: > Shouldn't it default to SERIALIZE_STATE_IN_SESSION = false if it's > such a performance killer? > > Travis > > On 11/3/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > > SERIALIZE_STATE_IN_SESSION and NUMBER_OF_VIEWS_IN_SESSION are only > > effective if STATE_SAVING_METHOD=server otherwise it´s settings will > > be ignored. > > > > The default for SERIALIZE_STATE_IN_SESSION is true and > > NUMBER_OF_VIEWS_IN_SESSION is 20 and are recommended if you use > > STATE_SAVING_METHOD=server to avoid strange side effects. > > > > 2005/11/3, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]>: > > > > > > So is there enough information at the moment to make a recommendation > > > about > > > how to set the parameters? For example: > > > > > > 1. If I set STATE_SAVING_METHOD=client, should I then set > > > SERIALIZE_STATE_IN_SESSION=false? > > > > > > 2. If I set STATE_SAVING_METHOD=server, should I then set > > > SERIALIZE_STATE_IN_SESSION=true? > > > > > > - Brendan > > > > > > -Original Message- > > > From: Vesa Lindfors [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 03, 2005 1:51 AM > > > Cc: MyFaces Discussion > > > Subject: Re: Some notes of my loadtest results > > > > > > > > > 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 <[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 > > > > >
Re: Some notes of my loadtest results
Shouldn't it default to SERIALIZE_STATE_IN_SESSION = false if it's such a performance killer? Travis On 11/3/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > SERIALIZE_STATE_IN_SESSION and NUMBER_OF_VIEWS_IN_SESSION are only > effective if STATE_SAVING_METHOD=server otherwise it´s settings will > be ignored. > > The default for SERIALIZE_STATE_IN_SESSION is true and > NUMBER_OF_VIEWS_IN_SESSION is 20 and are recommended if you use > STATE_SAVING_METHOD=server to avoid strange side effects. > > 2005/11/3, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]>: > > > > So is there enough information at the moment to make a recommendation about > > how to set the parameters? For example: > > > > 1. If I set STATE_SAVING_METHOD=client, should I then set > > SERIALIZE_STATE_IN_SESSION=false? > > > > 2. If I set STATE_SAVING_METHOD=server, should I then set > > SERIALIZE_STATE_IN_SESSION=true? > > > > - Brendan > > > > -Original Message- > > From: Vesa Lindfors [mailto:[EMAIL PROTECTED] > > Sent: Thursday, November 03, 2005 1:51 AM > > Cc: MyFaces Discussion > > Subject: Re: Some notes of my loadtest results > > > > > > 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 <[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. > >
Re: Some notes of my loadtest results
SERIALIZE_STATE_IN_SESSION and NUMBER_OF_VIEWS_IN_SESSION are only effective if STATE_SAVING_METHOD=server otherwise it´s settings will be ignored. The default for SERIALIZE_STATE_IN_SESSION is true and NUMBER_OF_VIEWS_IN_SESSION is 20 and are recommended if you use STATE_SAVING_METHOD=server to avoid strange side effects. 2005/11/3, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]>: > > So is there enough information at the moment to make a recommendation about > how to set the parameters? For example: > > 1. If I set STATE_SAVING_METHOD=client, should I then set > SERIALIZE_STATE_IN_SESSION=false? > > 2. If I set STATE_SAVING_METHOD=server, should I then set > SERIALIZE_STATE_IN_SESSION=true? > > - Brendan > > -Original Message- > From: Vesa Lindfors [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 03, 2005 1:51 AM > Cc: MyFaces Discussion > Subject: Re: Some notes of my loadtest results > > > 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 <[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 > >
Re: Some notes of my loadtest results
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 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
Title: Message So is there enough information at the moment to make a recommendation about how to set the parameters? For example: 1. If I set STATE_SAVING_METHOD=client, should I then set SERIALIZE_STATE_IN_SESSION=false? 2. If I set STATE_SAVING_METHOD=server, should I then set SERIALIZE_STATE_IN_SESSION=true? - Brendan -Original Message-From: Vesa Lindfors [mailto:[EMAIL PROTECTED] Sent: Thursday, November 03, 2005 1:51 AMCc: MyFaces DiscussionSubject: Re: Some notes of my loadtest results 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 <[EMAIL PROTECTED]> wrote: @Vesa could you run your tests again with the nightly and define thecontext param org.apache.myfaces.SERIALIZE_STATE_IN_SESSION with avalue 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 manyviews are held in the session (default = 20). This might cause agarbage 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
Re: Some notes of my loadtest results
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 <[EMAIL PROTECTED]> wrote: @Vesa could you run your tests again with the nightly and define thecontext param org.apache.myfaces.SERIALIZE_STATE_IN_SESSION with avalue 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 manyviews are held in the session (default = 20). This might cause agarbage 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
Re: Some notes of my loadtest results
@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
Re: Some notes of my loadtest results
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
Re: Some notes of my loadtest results
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
Re: Some notes of my loadtest results
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 >
Re: Some notes of my loadtest results
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
