Details

    • Similar issues:
      KULRICE-8798Look into multithreading during the view lifecycle
      KULRICE-7220Look into replacing component update process with full view lifecycle
      KULRICE-8797Reduce object creation in view lifecycle
      KULRICE-14087Several (hundreds) of transactions being created for a single request
      KULRICE-13147Inefficiencies in view lifecycle and rendering
      KULRICE-11062Do POC on changing lifecycle to use reflection
      KULRICE-3810JPA - Determine if Open Entity Manager in view filter will fix transaction issues
      KULRICE-10919RichMessageTest IT failures IllegalStateException: No view lifecycle is active on this thread
      KULRICE-8468Performance: Collect templates through view lifecycle and include once in view rendering
      KULRICE-13842Create transactional document view bean
    • Epic Link:
    • Rice Module:
      KRAD
    • Application Requirement:
      KS
    • Sprint:
      2.4.0-m2 KRAD Sprint 4, 2.4.0-m3 KRAD Sprint 1
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      The KSA transaction view is taking 22 seconds in the perform finalize. There is something going on that we have not caught in our performance testing:

      The main view that is causing the performance problems is our Transaction page.

      XML: https://svn.kuali.org/repos/student/contrib/ksa/trunk/ksa-core/src/main/resources/com/sigmasys/kuali/ksa/krad/TransactionView.xml

      I tried cutting down that page and found that the <bean id="runningBalanceList" parent="Uif-VerticalBoxGroup"> is the section that really takes a ton of time.

      -Tim

        Issue Links

          Activity

          Hide
          Mark Fyffe (Inactive) added a comment -

          Sorry for the delay - I need to complete KULRICE-12040 before I can bring KSA online without running into the same issues I'm seeing in krad-sampleapp. Will resume progress on this issue as soon as possible.

          Show
          Mark Fyffe (Inactive) added a comment - Sorry for the delay - I need to complete KULRICE-12040 before I can bring KSA online without running into the same issues I'm seeing in krad-sampleapp. Will resume progress on this issue as soon as possible.
          Hide
          Mark Fyffe (Inactive) added a comment -

          I worked toward a KSA setup from Rice trunk this weekend, but have run into a few challenges.

          KS-ENROLL M8 is not compatible with Rice 2.4, so I checked out and installed locally - https://svn.kuali.org/repos/student/enrollment/aggregate/branches/rice-2.4-mx-upgrade

          Once both the KS and Rice upgrades are in place, the KSA data dictionary initialization never completes. The last log message seen is below -

          24 Mar 2014 06:25:48,094 INFO  org.kuali.rice.krad.datadictionary.DefaultListableBeanFactory - Pre-instantiating singletons
          

          After this message, CPU activity is evident but no further progress on the init is made.

          I'm working to get this up and running in a debugger in order to identify where , but am not seeing consistent results between the debugger and stock Tomcat install. Atomikos fails to initialize properly in the debugger so the app doesn't get as far as initializing DD. I'll continue troubleshooting this week.

          Show
          Mark Fyffe (Inactive) added a comment - I worked toward a KSA setup from Rice trunk this weekend, but have run into a few challenges. KS-ENROLL M8 is not compatible with Rice 2.4, so I checked out and installed locally - https://svn.kuali.org/repos/student/enrollment/aggregate/branches/rice-2.4-mx-upgrade Once both the KS and Rice upgrades are in place, the KSA data dictionary initialization never completes. The last log message seen is below - 24 Mar 2014 06:25:48,094 INFO org.kuali.rice.krad.datadictionary.DefaultListableBeanFactory - Pre-instantiating singletons After this message, CPU activity is evident but no further progress on the init is made. I'm working to get this up and running in a debugger in order to identify where , but am not seeing consistent results between the debugger and stock Tomcat install. Atomikos fails to initialize properly in the debugger so the app doesn't get as far as initializing DD. I'll continue troubleshooting this week.
          Hide
          Mark Fyffe (Inactive) added a comment -

          All,

          When I last worked on this, I had significant trouble due to conflicts between KSA and Rice 2.4 at the middle layer. These conflicts may since been resolved by the KS effort to upgrade to Rice 2.4, but I have not yet cycled back to anther attempt. So far, I have not been able to bring KSA online to repeat analysis following the performance work we've put in for 2.4.

          However, I would like to suggest that we have just worked through a very similar issue for OLE based on Rice 2.3.4; based on my observations a few months ago, I think the approach recommended there may be beneficial for KSA. Tim, can you have a look at KULRICE-12476? I think the approach outlined there may be useful as a short-term fix if we can accurately identify the components that need to be prune from the view. Note that the difference between this approach and this recommended previously are that through a component override, the components may be pruned based on form data at the initialize phase where previous recommendations focus on suppressing rendering, which doesn't help to optimize the apply model phase. This approach, combined with the delayed copy feature added in Rice 2.4, I am optimistic that a viable solution for KSA can be reached.

          Best,
          Mark

          Show
          Mark Fyffe (Inactive) added a comment - All, When I last worked on this, I had significant trouble due to conflicts between KSA and Rice 2.4 at the middle layer. These conflicts may since been resolved by the KS effort to upgrade to Rice 2.4, but I have not yet cycled back to anther attempt. So far, I have not been able to bring KSA online to repeat analysis following the performance work we've put in for 2.4. However, I would like to suggest that we have just worked through a very similar issue for OLE based on Rice 2.3.4; based on my observations a few months ago, I think the approach recommended there may be beneficial for KSA. Tim, can you have a look at KULRICE-12476 ? I think the approach outlined there may be useful as a short-term fix if we can accurately identify the components that need to be prune from the view. Note that the difference between this approach and this recommended previously are that through a component override, the components may be pruned based on form data at the initialize phase where previous recommendations focus on suppressing rendering, which doesn't help to optimize the apply model phase. This approach, combined with the delayed copy feature added in Rice 2.4, I am optimistic that a viable solution for KSA can be reached. Best, Mark
          Hide
          Mark Fyffe (Inactive) added a comment -

          I have been looking into KSA this weekend, now that KS has mostly complete the upgrade to 2.4. We've worked a few very similar performance issues recently and have moved performance fixes in for 2.4.2 that may also serve to resolve the issues KSA has experienced.

          So far, I've been unsuccessful at completing initialization, but have tracked down the issue to classloader locking in Atomikos so am working to move database configurations to the webapp rather than Tomcat shared classloader. Given 2-3h effort, I should be able to get KSA up and running and collect new timings.

          One question first, though: the KSA project I've been working from hasn't been updated since March. Has KSA moved to a new repository location? It seems it will be best to work from a current version if one is available.

          Thanks,
          Mark

          Show
          Mark Fyffe (Inactive) added a comment - I have been looking into KSA this weekend, now that KS has mostly complete the upgrade to 2.4. We've worked a few very similar performance issues recently and have moved performance fixes in for 2.4.2 that may also serve to resolve the issues KSA has experienced. KULRICE-12633 KULRICE-12690 So far, I've been unsuccessful at completing initialization, but have tracked down the issue to classloader locking in Atomikos so am working to move database configurations to the webapp rather than Tomcat shared classloader. Given 2-3h effort, I should be able to get KSA up and running and collect new timings. One question first, though: the KSA project I've been working from hasn't been updated since March. Has KSA moved to a new repository location? It seems it will be best to work from a current version if one is available. Thanks, Mark
          Hide
          Mark Fyffe (Inactive) added a comment -

          I have not been able to get KSA to come up on Rice 2.4 or 2.5 due to ClassLoader issues related to the way I have Atomikos set up and the JPA configuration.

          Analysis on the KSA application in work related to this issue led to several performance updates that should address the TransactionView. These fixes are all in place on Rice 2.4.2 - I have only been unable to test due to local setup issues.

          Once KSA has been migrated to Rice 2.4, I expect that performance will be improved. I'm resolving the issue for now - it can be re-opened if the performance issues are still a problem on 2.4.

          Show
          Mark Fyffe (Inactive) added a comment - I have not been able to get KSA to come up on Rice 2.4 or 2.5 due to ClassLoader issues related to the way I have Atomikos set up and the JPA configuration. Analysis on the KSA application in work related to this issue led to several performance updates that should address the TransactionView. These fixes are all in place on Rice 2.4.2 - I have only been unable to test due to local setup issues. Once KSA has been migrated to Rice 2.4, I expect that performance will be improved. I'm resolving the issue for now - it can be re-opened if the performance issues are still a problem on 2.4.

            People

            • Assignee:
              Mark Fyffe (Inactive)
              Reporter:
              Tim Bornholtz (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 days Original Estimate - 2 days
                2d
                Remaining:
                Time Spent - 4 days, 3 hours Remaining Estimate - 3 hours
                3h
                Logged:
                Time Spent - 4 days, 3 hours Remaining Estimate - 3 hours
                4d 3h

                  Agile

                    Structure Helper Panel