Details
-
Bug
-
Resolution: Fixed
-
Low
-
3.1.9
Description
When doing request type searches via the Service Desk Portal page. We found that a significant amount of time is spent in:
base.AbstractJQLRequestTypeSearchAlgorithm.getRequestTypeSearchResults basic.BasicRequestTypeSearchAlgorithmTwo.findRequestTypes
Part of that call results in these queries:
42.9% - 5,207 ms - 4,336 hot spot evt. select "AO_54307E_GROUPTOREQUESTTYPE"."GROUP_ID", "AO_54307E_GROUP"."GROUP_NAME", "AO_54307E_GROUPTOREQUESTTYPE"."REQUEST_TYPE_ID" from "AO_54307E_GROUPTOREQUESTTYPE" "AO_54307E_GROUPTOREQUESTTYPE" join "AO_54307E_GROUP" "AO_54307E_GROUP" on "AO_54307E_GROUPTOREQUESTTYPE"."GROUP_ID" = "AO_54307E_GROUP"."ID" join "AO_54307E_VIEWPORTFORM" "AO_54307E_VIEWPORTFORM" on "AO_54307E_GROUPTOREQUESTTYPE"."REQUEST_TYPE_ID" = "AO_54307E_VIEWPORTFORM"."ID" where "AO_54307E_VIEWPORTFORM"."VIEWPORT_ID" = ?
- This is removed since 3.2.0, which should improve performance.
A second part to this is that it was found that the method "hides" pagination from it by querying next page when needed. This results in multiple redundant searches of request types and redundantly load associated objects (i.e. portal) for each request type for each search.
- This is fixed with 3.2.0