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-14084Improvements for Key Personnel Search Rendering
      KULRICE-14086Improvements for Key Personnel Page Rendering
      KULRICE-11146Improve visual treatment of dialogs
      KULRICE-4733Improve key values finder support
      KULRICE-786Improve the Rule Search screen
      KULRICE-843Improve wildcarding on all search screens
      KULRICE-8463allowing jstl key to be overriden
      KULRICE-14075Performance Profiling of KC
      KULRICE-3310Large SQL invocation count from Requisition Document Search
      KULRICE-10890Perform analysis & implementation on Key Personnel dialog
    • Epic Link:
    • Rice Module:
      KIM
    • Application Requirement:
      KC
    • Sprint:
      Middleware 2.5.2 Sprint 3
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      3

      Description

      In Key Personnel search (for employee or non-employee) performing the search operation is currently taking 28% of the response time.

      WizardControllerServiceImpl.java:51 org.kuali.coeus.common.view.wizard.impl.WizardControllerServiceImpl.preparePersonResults(Map) 7622 0 28%

      org.kuali.rice.kim.impl.identity.PersonServiceImpl.findPeopleInternal is slow (over 5 secs). Then there is a call to org.kuali.coeus.common.impl.person.KcPersonServiceImpl.createKcPersonsFromPeople that creates a KC person for each result which is slow as well (over 2 secs)

      Look into tuning PersonServiceImpl.findPeopleInternal and the overall search operation

        Issue Links

          Activity

          Hide
          Kurt McNew (Inactive) added a comment -

          to reproduce this via the UI:
          At the Coeus home screen goto Researcher->New Proposal.
          Fill out the seven fields, make sure to use (New) for the proposal type and (000001 - University) for the Lead Unit. Click save and continue
          Once the next screen loads click on the Key Personnel menu on the left side of the screen, from the dropdown menu click "Personnel".
          Click the blue add personnel button. An add person dialog will display, keep the employee radio button check, clicking the search button will hit the WizardControllerServiceImpl.preparePersonResults method.

          Show
          Kurt McNew (Inactive) added a comment - to reproduce this via the UI: At the Coeus home screen goto Researcher->New Proposal. Fill out the seven fields, make sure to use (New) for the proposal type and (000001 - University) for the Lead Unit. Click save and continue Once the next screen loads click on the Key Personnel menu on the left side of the screen, from the dropdown menu click "Personnel". Click the blue add personnel button. An add person dialog will display, keep the employee radio button check, clicking the search button will hit the WizardControllerServiceImpl.preparePersonResults method.
          Hide
          Claus Niesen added a comment -

          Preliminary findings:

          • Performance issue is not related to KRAD but to KIM
          • Non Employee search is significantly faster (but still not great)
          • Performance can be improved by reducing the result set:
            • Adding a criteria condition to the search
            • limiting the number of lines returned
          • Server side paging didn't help much. It went from 9,025 down to 8,951. But introduced paging issues and appears to be flaky with the wizard.
          • Wizzard's use of PersonServiceImpl.findPeople is 7,933 while the KIM Person Screen usage of PersonLookupableHelperServiceImpl.getSearchResults is 7,961. Performance is comparable even though implementations are different.
          Show
          Claus Niesen added a comment - Preliminary findings: Performance issue is not related to KRAD but to KIM Non Employee search is significantly faster (but still not great) Performance can be improved by reducing the result set: Adding a criteria condition to the search limiting the number of lines returned Server side paging didn't help much. It went from 9,025 down to 8,951. But introduced paging issues and appears to be flaky with the wizard. Wizzard's use of PersonServiceImpl.findPeople is 7,933 while the KIM Person Screen usage of PersonLookupableHelperServiceImpl.getSearchResults is 7,961. Performance is comparable even though implementations are different.
          Hide
          Claus Niesen added a comment - - edited

          Note: consider fetching with @NamedEntityGraph (see DocumentRouteHeaderValue.ActionListAttributesOnly for an example)

          Fetching of following EntityBo attributes required:

          • principals
          • privacyPreferences
          • names
          • entityTypeContactInfos
          • affiliations
          • employmentInformation
          • externalIdentifiers

          Update: This was addressed by KULRICE-14112 which reduced the response time significantly but still not to an acceptable level.

          Show
          Claus Niesen added a comment - - edited Note: consider fetching with @NamedEntityGraph (see DocumentRouteHeaderValue.ActionListAttributesOnly for an example) Fetching of following EntityBo attributes required: principals privacyPreferences names entityTypeContactInfos affiliations employmentInformation externalIdentifiers Update: This was addressed by KULRICE-14112 which reduced the response time significantly but still not to an acceptable level.
          Hide
          Claus Niesen added a comment -

          Adding server side paging p:useServerPaging="true to KC-Wizard-Results (of WizardCommon.xml) achieved an acceptable response time of 2 seconds.

          However the paging buttons are not rendered when enabling server side paging and a JavaScript error is thrown. Initial investigations indicate an issue with the richTable.templateOptions of the KC-Wizard-Results bean.

          Show
          Claus Niesen added a comment - Adding server side paging p:useServerPaging="true to KC-Wizard-Results (of WizardCommon.xml) achieved an acceptable response time of 2 seconds. However the paging buttons are not rendered when enabling server side paging and a JavaScript error is thrown. Initial investigations indicate an issue with the richTable.templateOptions of the KC-Wizard-Results bean.
          Hide
          Claus Niesen added a comment -

          KULRICE-14084 has implemented light tables for the lookup. With that improvement and KULRICE-14112 the Key Personnel Search should be fine.

          Show
          Claus Niesen added a comment - KULRICE-14084 has implemented light tables for the lookup. With that improvement and KULRICE-14112 the Key Personnel Search should be fine.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Agile

                  Structure Helper Panel