myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Heinz <mhz4...@gmail.com>
Subject Re: Performance issue with component bindings and Ajax requests
Date Wed, 20 Aug 2014 07:41:57 GMT
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 <lu4242@gmail.com> 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 <mhz4248@gmail.com>:
> > 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:
> > <h:panelGroup id="formRoot" binding="#{FormBean.formRoot}"/>
> >
> > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message