Slow loading Kanban board when filter uses project category and exclude an issue type and a project

[Nicolas Bourdages (Ubisoft)]

This one is very weird. I'm investigating why a Kanban board is loading slowly, and I found something quite surprising: When using a project category as the basis of the JQL and then excluding specific projects and issue types, the board is a lot slower (several minutes) instead of 2-3 seconds. Here's how I went about this:

• category = [projectCategory] and type != [issuetype]: Fast (17k issues)
• category = [projectCategory] project != [projectName]: Fast (17k issues)
• category = [projectCategory] and type !=[issuetype] and project != [projectName]: Very slow!!! (16k issues)

This seems counterintuitive, since a more restrictive filter that returns fewer issues should load at least a tiny bit faster. I went and made more tests:

category = [projectCategory] project != [projectName] AND and type in ([all other issue types]): Fast (16k issues)

That's nonsensical, it's the results as the query that's slow, I just substituted the "type != [issuetype]" with a list of all issue types used in these projects. 

Further tests:

• category = [projectCategory] and type != [issuetype] and status not in (done, closed): Very fast (1400 issues)
• category = [projectCategory] and type != [issuetype] and status not in (done, closed) AND project != [projectName] : Very slow (1200 issues)

In all these cases, the JQL itself is reasonably fast, 50-100ms. It's really the Kanban board loading that's affected by the JQL syntax more than by the number of results, and it's extremely weird. Anybody else has seen something like this? I couldn't find anything on Answers or in the Atlassian Jira.

Thanks,

Nicolas

[Nicolas Bourdages (Ubisoft)]

I found the source if the issue. It was a Jira service (/rest/greenhopper/1.0/rapidviewconfig/editmodel.json). It has very poor performances on large instances with hundreds of projects and issue types if specific JQLs are used to exclude projects and issuetypes from a project category search, even though the JQL itself is very fast. That service is called when loading a board's config screen, but may also be used by plugins to provide additional functionalities to Agile boards, which was the reason why we noticed the problem in some of our Kanban boards. The number of issues returned by the filter is irrelevant, the response time is correlated with the total number of projects and issuetypes on the instance, not with the actual contents of the JQL.

Workaround is basically just avoiding such JQLs. Using the sub-filter to complement the query with "issuetype != myIssueType" also improves the situation.

[Prem Chudzinski _extensi_]

Hello @Nicolas Bourdages (Ubisoft) 

we’re looking into it.