myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Heinz <>
Subject Performance issue with component bindings and Ajax requests
Date Tue, 19 Aug 2014 13:12:31 GMT
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

In our facelet:
<h:panelGroup id="formRoot" binding="#{FormBean.formRoot}"/>

Our backing bean:

public class FormBean {
     private boolean rebuildDone = false;
     private UIPanel formRoot;
     public UIPanel getFormRoot() {
          if (!rebuildDone) {
          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.

          // Clear the existing tree.

          // 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:
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,


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