Long time of response transitioning from issues view to agile board

emilianooliver

Hi dear JIRA users,

A few weeks ago we notice that when pressing "More" -> "Agile Board" button from an issue, it takes a lot of time to show that issue on the board. We thought that it may be a problem within the amount of issues submitted on the project, or the issues displayed on the agile board, but then we check it with a project that have only 5 issues, and the time of response is still very slow (from 1 to 2 minutes). We ask about this to our infrastructure area, but it says that the requirements are fine.

What do you think about this problem? 

Thanks in advance!!

crf

See https://jira.atlassian.com/browse/GHS-8775

JIRA Agile does not "just know" which board(s) an issue is on; it must try out the JQL from every board in the system to see if your issue turns up in the results or not.  This is fixed if you are running JIRA Agile 6.6.0 with JIRA 6.4 (not yet released, but it should be available soon).

The fix involves building a temporary index that contains only that issue so that multiple JQL queries can be run against it very quickly, but this requires support from JIRA itself, hence the need to be on JIRA 6.4 to take advantage of it.

In the meantime, the best advice I can give is to watch the atlassian-jira-slow-queries.log file as you attempt this.  Very likely, one or more of the agile boards on the system has very expensive JQL and will show up there.  You can then track this back to those agile boards and try to optimize the queries that they are using.

This is a whole topic in itself, but one quick tip I can give you is to try to avoid using expressions like filter IN (...) to join multiple queries together.  You might be tempted to do this when you have several sub-projects and want to also have a board that composes all of them, but this is implemented by nesting those queries, so it can be very expensive.  If you can express that sort of thing more simply, such as just with project IN (...), you will get much better performance in general.  There are also certain JQL functions, particularly those provided by third party developers or that are not maintained, that never really get tested on large instances, so that's another thing you can keep an eye out for.