You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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:
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.
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.
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.