Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.5.2
    • Component/s: Performance
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-14075Performance Profiling of KC
      KULRICE-13450Load Test Data - DB access tool
      KULRICE-7938Data for Creating a separate permission for accessing the new super user tab
      KULRICE-7714Performance improvements in regards to workflow data access
      KULRICE-6519Service which deal with cross-application data should implement appropriate fine-grained security models for access to that data
      KULRICE-7009Profile the view process (complete request/response) for bottlenecks
      KULRICE-8349Insert guest KIM data in master data source
      KULRICE-9429Profile Kitchen Sink pages using App Dynamics
      KULRICE-12410Modify KEW so the rule tables are accessed directly in embedded mode
      KULRICE-8867Applications access data via Rest services versus via direct database access
    • Epic Link:
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      KIM Integration
    • Application Requirement:
      KC
    • Sprint:
      Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      5

      Description

      Data Access is accounting for a large part of the response time on many proposal requests. One were it is very evident is the questionnaire page. Here we have the following responses accounting for 36% of the response time:

      ProposalDevelopmentQuestionnaireController.java:63 org.kuali.coeus.propdev.impl.core.ProposalDevelopmentViewHelperServiceImpl.populateQuestionnaires(ProposalDevelopmentDocumentForm) 4096 0

      ProposalDevelopmentControllerBase.java:350 org.kuali.coeus.propdev.impl.core.ProposalDevelopmentControllerBase.save(ProposalDevelopmentDocumentForm) 1145 0

      These lead to potential bottlenecks in Rice itself. Profile this further looking for the following:

      1) How can the number of queries be reduced
      2) Was does saving the document take so long?
      3) What is causing the OJB get collection by query to take so long?
      org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Query) 1750 687 12%
      4) How can we reduce the layers on the Rice side coming from the provider and adapter functionality?
      org.kuali.rice.krad.data.jpa.JpaPersistenceProvider$9.call() JpaPersistenceProvider.java 1203 8%

      org.kuali.rice.krad.data.provider.impl.ProviderRegistryImpl.getPersistenceProvider(Class) ProviderRegistryImpl.java:147 1062

      FunctionBoServiceImpl.java:150 org.kuali.rice.krad.data.provider.impl.ProviderBasedDataObjectService.find(Class, Object) 265 0

        Issue Links

          Activity

          Hide
          Christopher Wade (Inactive) added a comment -

          Suggestions:

          1) QuestionaireServiceImpl.isCurrentQuestionaire can be improved by using a sql with a max(sequenceNumber) instead of loading all by sequence number and just choosing the first one.
          2) questiaire_id and sequence number(asc) in an index for questionaire database table
          3) KRMS improvements will also help too

          Show
          Christopher Wade (Inactive) added a comment - Suggestions: 1) QuestionaireServiceImpl.isCurrentQuestionaire can be improved by using a sql with a max(sequenceNumber) instead of loading all by sequence number and just choosing the first one. 2) questiaire_id and sequence number(asc) in an index for questionaire database table 3) KRMS improvements will also help too
          Hide
          Claus Niesen added a comment -

          The refactoring of the isCurrentQuestionnaire to use a custom DAO did not show any significant performance improvement. I'm not sure if the code will make a difference on an actual KC implementation with more data.
          Patch: KULRICE-14083_isCurrentQuestionnaire_refactor.patch
          Pull request: https://github.com/kuali/kc/pull/1359

          Show
          Claus Niesen added a comment - The refactoring of the isCurrentQuestionnaire to use a custom DAO did not show any significant performance improvement. I'm not sure if the code will make a difference on an actual KC implementation with more data. Patch: KULRICE-14083 _isCurrentQuestionnaire_refactor.patch Pull request: https://github.com/kuali/kc/pull/1359
          Hide
          Claus Niesen added a comment -

          Resolving issue since the performance is in an acceptable range for KC.

          Show
          Claus Niesen added a comment - Resolving issue since the performance is in an acceptable range for KC.

            People

            • Assignee:
              Christopher Wade (Inactive)
              Reporter:
              Jerry Neal (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Agile

                  Structure Helper Panel