Performance updates to Jira epic picker
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Environment
Jira Data Center 8.22.0 (8.20.7/8.13.20) and later
Starting from versions 8.22.0 and backported on versions 8.20.7 and 8.13.20, Jira has a new mechanism to retrieve epics for epic picker (its AJAX endpoint) and epic autocomplete suggestions. See the following ticket for more details: JSWSERVER-21026 - Epic link dropdown slow in large instances.
Problem
Before this update, Jira was trying to fetch all epics available to a user from the index and then filter them by using a special Java class.
This mechanism allowed for very precise grouping and filtering of epics. However, each read of the Lucene document increased the time of loading the results, so the time of the response grew linearly and was quite significant beyond 100,000 - 200,000 epics (>5s).
Solution
To solve the problem, we've decided to use JQL queries to retrieve matching epics for both epic picker sections: prioritized and other epics. Epic picker will now retrieve suggestions using one or two simple JQL queries, which ensures a predictable response time.
We tested the solution with 500,000 epics and the response time was below 2s.
The resulting JQLs perform a search with the following search criteria:
issue type = Epic
in
/not in
(a list of projects) Optionalsummary
orissue key ~ searchTerm
Optionalepic done status (not an issue status) is
true
orfalse
Optional
Epics are always ordered by issue key in descending order. Potentially, this limits epics visibility and exposes epic picker to any issues found in JQL, for example: JRASERVER-30978 - JQL query autocomplete problem with usernames that contain Turkish "I" character
The filterEpicByGivenProjects
parameter in REST API is now effectively unused since it can be controlled by the projectKey
parameter.
Reverting the change
If you want to revert to the old mechanism, you need to enable the following dark feature: com.atlassian.jira.agile.darkfeature.legacy.epic.picker
. For details, see How to manage dark features in Jira Server and Data Center.
We don't recommend this approach as it might cause performance degradation to over 100,000 epics.