nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Agile Board is Unuseably Slow

Nicole Williams2

I just took over an Agile board, and it is so slow I can't use it. If I even click on anything my browser hangs for 30 seconds.

The Board

When I click on the board and go to the associated filter, it literally shows every ticket in our system.

Our columns are mapped to 8 statuses.

We use filters as swimlanes (approximately 30)

We have quickfilters by assignee(20) plus 2 quickfilters for updated recently.

Obviously it's pulling WAY to much data, but I was wondering if there are best practices for optimizing the query. I can't limit it to one project because the versions span multiple projects. I could limit it by assignee, but there are 20 people. Is there a maximimum number of quickfilters or filters I should be limiting myself to?

Please help.

Accepted answers

All comments

Nic Brough -Adaptavist-

The quickfilters only really kick in when you use them. I find the main things that load a board are the baseline query and (to a lesser extent) the swimlanes, as they're all directly involved in the rendering up-front.

30 seconds a click is by FAR too slow. To investigate, could you try a quick test - create a new board with the same filter, but no swimlanes or quick-filters. Don't put any sprints or new epics on it either. Now, how does that handle? Does it seem ok?

Secondly, how many issues does the baseline board filter pull back? Cross-project shouldn't matter too much, but if the filter is pulling in 1000's of issues, then that could be a significant part of the problem.

Daniel Wester

What browser are you using? Older IE versions can be slow...

Matthew Gately

While this may not help the original poster, I want to comment on one of your statements that may help others who arrive at this page (it helped me!).

You say "Cross-project shouldn't matter too much." In my case, the cross-project aspect of my filter query is the only thing that mattered.

I had a filter query that returned on 64 results, so very minimal. However, the filter query didn't have any explicit statements like "project in (a,b)". The Agile board then assumed that the filter query involved all 278 projects from my company, while it really only included items from 5. With this query, it took like 30 seconds to load the page, and again after any editing of a ticket. Also, dragging items was pretty much impossible.

When I looked at the filter configuration, it listed the board as having 278 projects, which tipped me off to the problem. Once I updated the query to make sure that the Agile board parser could easily tell the number of projects the filter would return, it fixed everything up.

Again, let me stress, my filter results were identical to before (64 tickets), however, the Agile board processor must have quite a bit of logic involved in checking all projects it thinks could be returned by the filter. Simply updating the filter, but in a way that still returned the same results, fixed my latency issue.

Nic Brough -Adaptavist-

mmm, 4 year old post... Things have changed.

Jack Brickey

hey it's a slow thread! ;-)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud