Re: Performance issue with component bindings and Ajax requests
Hi I checked the algorithm and I have also fixed the problem (committed in 2.0.x, 2.1.x and 2.2.x). See: https://issues.apache.org/jira/browse/MYFACES-3918 I think the solution is ok, but an extra test could be also helpful. regards, Leonardo 2014-08-20 2:45 GMT-05:00 l.pe...@senat.fr : > On 20/08/2014 09:41, Marc Heinz wrote: >> >> Thanks for the quick answer! >> >> We tried disabling PSS but this actually broke several other things, so we >> would prefer not to touch it right now. >> >> Setting the flag "org.apache.myfaces.REMOVING_COMPONENTS_BUILD" however >> seems to do the trick... (we though about using it before but we were >> unsure about the possible implications). >> >> I've created an issue as suggested: >> https://issues.apache.org/jira/browse/MYFACES-3918 >> >> I will report any possible regression we find there, and I will test again >> when a fix becomes available. > > I am also interesting by this issue and ready to test a fix in the days to > come. > > Ludovic > | > | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. > | >
Re: Performance issue with component bindings and Ajax requests
On 20/08/2014 09:41, Marc Heinz wrote: Thanks for the quick answer! We tried disabling PSS but this actually broke several other things, so we would prefer not to touch it right now. Setting the flag "org.apache.myfaces.REMOVING_COMPONENTS_BUILD" however seems to do the trick... (we though about using it before but we were unsure about the possible implications). I've created an issue as suggested: https://issues.apache.org/jira/browse/MYFACES-3918 I will report any possible regression we find there, and I will test again when a fix becomes available. I am also interesting by this issue and ready to test a fix in the days to come. Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Performance issue with component bindings and Ajax requests
Thanks for the quick answer!
We tried disabling PSS but this actually broke several other things, so we
would prefer not to touch it right now.
Setting the flag "org.apache.myfaces.REMOVING_COMPONENTS_BUILD" however
seems to do the trick... (we though about using it before but we were
unsure about the possible implications).
I've created an issue as suggested:
https://issues.apache.org/jira/browse/MYFACES-3918
I will report any possible regression we find there, and I will test again
when a fix becomes available.
Once again, thanks a lot for the reactivity.
Marc
On Tue, Aug 19, 2014 at 8:42 PM, Leonardo Uribe wrote:
> Hi
>
> The problem is the call to formRoot.getChildren().clear() activates
> the listener for
> PreRemoveFromViewEvent and that one register the removed components. Since
> you are generating over and over components, after many requests that list
> becomes big.
>
> I can imagine two solutions:
>
> 1. Disable PSS on the affected views, using
> javax.faces.FULL_STATE_SAVING_VIEW_IDS param
>
> 2. Try to use this code on formRoot.getChildren().clear();
>
>
> facesContext.getAttributes.put("org.apache.myfaces.REMOVING_COMPONENTS_BUILD",
> Boolean.TRUE);
> formRoot.getChildren().clear();
>
> facesContext.getAttributes.remove("org.apache.myfaces.REMOVING_COMPONENTS_BUILD");
>
> That will avoid register the ids on the list, without side effects
> (that I can imagine right now,
> not 100% sure).
>
> Anyway, It is possible to find a solution changing the code in
> DefaultFaceletsStateManagementStrategy, so the list keeps stable over time,
> Please create an issue on MyFaces issue tracker:
>
> https://issues.apache.org/jira/browse/MYFACES
>
> regards,
>
> Leonardo Uribe
>
> 2014-08-19 8:12 GMT-05:00 Marc Heinz :
> > Hello everybody,
> >
> > We are currently encountering some performances issues with myfaces, and
> we
> > would really appreciate some help on the subject.
> >
> > We are generating forms to be filled by the user dynamically (through
> > component binding) from a set of externally managed rules. Here is a
> short
> > overview:
> >
> > In our facelet:
> >
> >
> > Our backing bean:
> >
> > @RequestScoped
> > public class FormBean {
> > private boolean rebuildDone = false;
> > private UIPanel formRoot;
> > public UIPanel getFormRoot() {
> > if (!rebuildDone) {
> >rebuildForm();
> > }
> > return formRoot;
> > }
> > public void setFormRoot(UIPanel formRoot) {
> >// Ignore.
> > }
> > // Public method to rebuild the current form content in reaction to
> > updates fired from Ajax managed components.
> > public void rebuildForm() {
> > if (formRoot == null) {
> > formRoot = new UIPanel();
> > // The whole component tree is marked as transient.
> > formRoot.setTransient(true);
> > formRoot.setId("formRoot");
> > }
> >
> > // Clear the existing tree.
> > formRoot.getChildren().clear();
> >
> > // Start building the new component tree with formRoot as
> parent.
> > [...]
> > }
> > }
> >
> > We use Ajax extensively: all updates events are processed with
> > AjaxBehaviorsListeners (wired on "onchange" client events).
> >
> > When a change is processed (during the INVOKE_APPLICATION phase), the
> value
> > is validated and the GUI is refreshed by calling the "rebuildForm()"
> > method. The existing component tree will then be *cleared* by calling
> > getChildren().clear() on the binding root component. It will be then
> > rebuilt entirely (even though only a small subset of components are
> usually
> > affected). This is clearly inefficient, but this is some legacy code that
> > we don't want to disturb unless strictly required.
> >
> > What we observed (with MyFaces 2.1.12 and the 2.1.16 r1618150 in trunk):
> on
> > all forms (but especially on forms with all lot of components) every Ajax
> > request takes more time to complete than the previous one as long as we
> > stay on the same view. On a form with ~70 fields, the turnaround time
> > (measured with the Net panel of Firebug) goes from ~250ms (first request)
> > to more than 1 second after ~15 update.
> >
> > After some profiling done with VisualVM, we pinpointed the location of
> the
> > latency to:
> >
> org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.handleDynamicAddedRemovedComponents(),
> > accountable for > 70% of the processing time. On further inspection, it
> > appears that a data structure, the list of removed client IDs
> > (clientIdsRemoved), is growing endlessly across each request.
> >
> > We are not too sure where the problem is right now... Should we build the
> > component tree only once during the RESTORE_VIEW phase and then update
> it?
> > (this seems hardly doable) Are we simply doing something in the wrong
> > phase? Should I raise an issue on this?
> >
> > Any feedback
Re: Performance issue with component bindings and Ajax requests
Hi
The problem is the call to formRoot.getChildren().clear() activates
the listener for
PreRemoveFromViewEvent and that one register the removed components. Since
you are generating over and over components, after many requests that list
becomes big.
I can imagine two solutions:
1. Disable PSS on the affected views, using
javax.faces.FULL_STATE_SAVING_VIEW_IDS param
2. Try to use this code on formRoot.getChildren().clear();
facesContext.getAttributes.put("org.apache.myfaces.REMOVING_COMPONENTS_BUILD",
Boolean.TRUE);
formRoot.getChildren().clear();
facesContext.getAttributes.remove("org.apache.myfaces.REMOVING_COMPONENTS_BUILD");
That will avoid register the ids on the list, without side effects
(that I can imagine right now,
not 100% sure).
Anyway, It is possible to find a solution changing the code in
DefaultFaceletsStateManagementStrategy, so the list keeps stable over time,
Please create an issue on MyFaces issue tracker:
https://issues.apache.org/jira/browse/MYFACES
regards,
Leonardo Uribe
2014-08-19 8:12 GMT-05:00 Marc Heinz :
> Hello everybody,
>
> We are currently encountering some performances issues with myfaces, and we
> would really appreciate some help on the subject.
>
> We are generating forms to be filled by the user dynamically (through
> component binding) from a set of externally managed rules. Here is a short
> overview:
>
> In our facelet:
>
>
> Our backing bean:
>
> @RequestScoped
> public class FormBean {
> private boolean rebuildDone = false;
> private UIPanel formRoot;
> public UIPanel getFormRoot() {
> if (!rebuildDone) {
>rebuildForm();
> }
> return formRoot;
> }
> public void setFormRoot(UIPanel formRoot) {
>// Ignore.
> }
> // Public method to rebuild the current form content in reaction to
> updates fired from Ajax managed components.
> public void rebuildForm() {
> if (formRoot == null) {
> formRoot = new UIPanel();
> // The whole component tree is marked as transient.
> formRoot.setTransient(true);
> formRoot.setId("formRoot");
> }
>
> // Clear the existing tree.
> formRoot.getChildren().clear();
>
> // Start building the new component tree with formRoot as parent.
> [...]
> }
> }
>
> We use Ajax extensively: all updates events are processed with
> AjaxBehaviorsListeners (wired on "onchange" client events).
>
> When a change is processed (during the INVOKE_APPLICATION phase), the value
> is validated and the GUI is refreshed by calling the "rebuildForm()"
> method. The existing component tree will then be *cleared* by calling
> getChildren().clear() on the binding root component. It will be then
> rebuilt entirely (even though only a small subset of components are usually
> affected). This is clearly inefficient, but this is some legacy code that
> we don't want to disturb unless strictly required.
>
> What we observed (with MyFaces 2.1.12 and the 2.1.16 r1618150 in trunk): on
> all forms (but especially on forms with all lot of components) every Ajax
> request takes more time to complete than the previous one as long as we
> stay on the same view. On a form with ~70 fields, the turnaround time
> (measured with the Net panel of Firebug) goes from ~250ms (first request)
> to more than 1 second after ~15 update.
>
> After some profiling done with VisualVM, we pinpointed the location of the
> latency to:
> org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.handleDynamicAddedRemovedComponents(),
> accountable for > 70% of the processing time. On further inspection, it
> appears that a data structure, the list of removed client IDs
> (clientIdsRemoved), is growing endlessly across each request.
>
> We are not too sure where the problem is right now... Should we build the
> component tree only once during the RESTORE_VIEW phase and then update it?
> (this seems hardly doable) Are we simply doing something in the wrong
> phase? Should I raise an issue on this?
>
> Any feedback would be most appreciated,
>
> Thanks,
> Marc
Performance issue with component bindings and Ajax requests
Hello everybody,
We are currently encountering some performances issues with myfaces, and we
would really appreciate some help on the subject.
We are generating forms to be filled by the user dynamically (through
component binding) from a set of externally managed rules. Here is a short
overview:
In our facelet:
Our backing bean:
@RequestScoped
public class FormBean {
private boolean rebuildDone = false;
private UIPanel formRoot;
public UIPanel getFormRoot() {
if (!rebuildDone) {
rebuildForm();
}
return formRoot;
}
public void setFormRoot(UIPanel formRoot) {
// Ignore.
}
// Public method to rebuild the current form content in reaction to
updates fired from Ajax managed components.
public void rebuildForm() {
if (formRoot == null) {
formRoot = new UIPanel();
// The whole component tree is marked as transient.
formRoot.setTransient(true);
formRoot.setId("formRoot");
}
// Clear the existing tree.
formRoot.getChildren().clear();
// Start building the new component tree with formRoot as parent.
[...]
}
}
We use Ajax extensively: all updates events are processed with
AjaxBehaviorsListeners (wired on "onchange" client events).
When a change is processed (during the INVOKE_APPLICATION phase), the value
is validated and the GUI is refreshed by calling the "rebuildForm()"
method. The existing component tree will then be *cleared* by calling
getChildren().clear() on the binding root component. It will be then
rebuilt entirely (even though only a small subset of components are usually
affected). This is clearly inefficient, but this is some legacy code that
we don't want to disturb unless strictly required.
What we observed (with MyFaces 2.1.12 and the 2.1.16 r1618150 in trunk): on
all forms (but especially on forms with all lot of components) every Ajax
request takes more time to complete than the previous one as long as we
stay on the same view. On a form with ~70 fields, the turnaround time
(measured with the Net panel of Firebug) goes from ~250ms (first request)
to more than 1 second after ~15 update.
After some profiling done with VisualVM, we pinpointed the location of the
latency to:
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.handleDynamicAddedRemovedComponents(),
accountable for > 70% of the processing time. On further inspection, it
appears that a data structure, the list of removed client IDs
(clientIdsRemoved), is growing endlessly across each request.
We are not too sure where the problem is right now... Should we build the
component tree only once during the RESTORE_VIEW phase and then update it?
(this seems hardly doable) Are we simply doing something in the wrong
phase? Should I raise an issue on this?
Any feedback would be most appreciated,
Thanks,
Marc
