ICEfaces
  1. ICEfaces
  2. ICE-11255

ace:fileEntry - Performance issues after uploading files

    Details

      Description

      A customer has been doing some performance testing of their application using ICEfaces EE 3.3.0 P04. After uploading many files they are seeing a drastic reduction in performance of the application.

      Here is their analysis:

      In our performance tests with P04 we encountered heavy performance issues!

      We have the <ace:fileEntry> component in our application to allow users to upload files.
      Our performance tests are uploading about 180 different files within 8 hours. We've run 6 runs of those 8 hours period and the tomcat performance has become really bad.
      Actions that usually took milliseconds do now need several seconds (just changes in the view without backend interaction).

      We took a heapdump from the tomcat.
      In the heapdump (see attached file FileEntryFormSubmit_ReEnableCaptureSubmit_all_ice_classes.PNG) you will find 146.876 "ReEnableCaptureSubmit.class" instances.
      In comparison to other objects in the heap, this amount of objects is very large.

      While the performance tests are continueing (with horrible respond times in all userinterfaces (xhtmls), not just at the part where the upload component is used) we took several threaddumps from tomcat. (see attached threaddump_3793_170301_0839.txt)
      In those threaddumps you can find RUNNABLE threads that look like this:
      "http-bio-13081-exec-2861" #13041 daemon prio=5 os_prio=64 tid=0x0000000000d9d800 nid=0x32f3 runnable [0xffff80ff9f1e7000]
      java.lang.Thread.State: RUNNABLE
      at javax.faces.component.UIComponentBase.getFacetsAndChildren(UIComponentBase.java:721)
      at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:641)
      at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:648)
      at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:648)
      at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.java:600)
      at org.icefaces.ace.component.fileentry.FileEntryFormSubmit$ReEnableCaptureSubmit.processEvent(FileEntryFormSubmit.java:223)
      at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106)
      ...
      ...
      - locked <0x0000000776d06110> (a org.apache.tomcat.util.net.SocketWrapper)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
      at java.lang.Thread.run(Thread.java:745)

      Each of those threads take about 2% of our CPU. So if we have 10 of those threads that is already 20% CPU usage.

      Our questions:
      1. The question is, how come there is such a massive amount of those "ReEnableCaptureSubmit.class" objects and these have so much impact on the performance? Maybe there is a context with http://jira.icesoft.org/browse/ICE-10866?
      2. Why we have performance kill threads on org.icefaces.ace.component.fileentry.FileEntryFormSubmit$ReEnableCaptureSubmit.processEvent(FileEntryFormSubmit.java:223)? What is the cause? Why do they need so much CPU?

        Activity

        Hide
        Mircea Toma added a comment -

        Indeed we had a glaring bug here. The ReEnableCaptureSubmit listener instances are added on each JSF lifecycle but its removal occurs only when the file is uploaded.

        Show
        Mircea Toma added a comment - Indeed we had a glaring bug here. The ReEnableCaptureSubmit listener instances are added on each JSF lifecycle but its removal occurs only when the file is uploaded.
        Hide
        Mircea Toma added a comment -

        Removed ReEnableCaptureSubmit listener since is not necessary to restore the DISABLE_CAPTURE_SUBMIT form attribute. The attribute will be discarded anyway whenever the component tree is changed.

        Show
        Mircea Toma added a comment - Removed ReEnableCaptureSubmit listener since is not necessary to restore the DISABLE_CAPTURE_SUBMIT form attribute. The attribute will be discarded anyway whenever the component tree is changed.
        Hide
        Mircea Toma added a comment -

        A relevant test would be to have two almost identical views that you can switch between without a page reload. The first view should contain a form that includes the file entry while the second view should have the same markup (with same IDs) but the form does not contain the file entry component. When navigating from first to second view and then submitting the form (in the second) we should observe an AJAX post-back, in case a HTML POST is issued then the test has failed.
        That's the only test I can think of that does not involve a debbuger.

        Show
        Mircea Toma added a comment - A relevant test would be to have two almost identical views that you can switch between without a page reload. The first view should contain a form that includes the file entry while the second view should have the same markup (with same IDs) but the form does not contain the file entry component. When navigating from first to second view and then submitting the form (in the second) we should observe an AJAX post-back, in case a HTML POST is issued then the test has failed. That's the only test I can think of that does not involve a debbuger.
        Hide
        Mircea Toma added a comment -

        Okay, I modified the test to use forward navigation between pages. When clicking the "Test" button to submit the form in the second page it runs as an AJAX post-back as expected.

        Show
        Mircea Toma added a comment - Okay, I modified the test to use forward navigation between pages. When clicking the "Test" button to submit the form in the second page it runs as an AJAX post-back as expected.
        Hide
        Arturo Zambrano added a comment -

        This issue is failing on MyFaces. The new view is not loaded when pressing the 'Next Page' button.

        Show
        Arturo Zambrano added a comment - This issue is failing on MyFaces. The new view is not loaded when pressing the 'Next Page' button.
        Hide
        Mircea Toma added a comment -

        I see the new view as being loaded after 'Next Page' button is clicked. I made sure I'm indeed running with Myfaces. Maybe you had a deployment issue?

        Show
        Mircea Toma added a comment - I see the new view as being loaded after 'Next Page' button is clicked. I made sure I'm indeed running with Myfaces. Maybe you had a deployment issue?
        Hide
        Arturo Zambrano added a comment -

        Thank you for testing this, Mircea. Now that I redeployed and tested again, the test is working correctly. The new view is being loaded after the 'Next Page' button is clicked, and pressing the 'Test' button sends an ajax request to the second page, as expected. I don't know what could've caused the issue the first time.

        Show
        Arturo Zambrano added a comment - Thank you for testing this, Mircea. Now that I redeployed and tested again, the test is working correctly. The new view is being loaded after the 'Next Page' button is clicked, and pressing the 'Test' button sends an ajax request to the second page, as expected. I don't know what could've caused the issue the first time.

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Arran Mccullough
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: