Very slow Gantt OnDemand - are we doing it wrong?

Hi - we are evaluating Gntt OnDemand for our JIRA and are curently having performance issues. We have about 40 issues with dependencies and when we try to render the hcat, it takes ages.

I am aware that this is a beta, but still....anything we can do to optimize?



6 answers

1 accepted

0 votes
Accepted answer

Hi Christian, it is very unlikely that rendering so few issues "takes ages" so I'm a bit supprised. Can you give me your Jira instance url so I'll take a look into logs and see if there's anything unusual?

From what I can see, you got ~1500 issues out there. Even though, you are using filters to show only a few from one project, the rest is still coming from backend and is being pre-processed which takes time. I suggest you to archive some old projects. You can read more about it in documentation here:

Let me know if that helped. Also, we improved the way in which chart is re-rendered after start date change so you may also notice a nice performance improvement here.

Ah, that is a problem - when loading Gantt OnDemand, we currently have to choose the project we don't want - couldn't it be the other way round?

Currently we have 500 open issues and 1000 closed - archiving them will defeat the purpose of using JIRA. My prognosis tells me that 6 months from now we will have 1000 open and 2500 closed issues across 40 projects. Since each project is either linked to a customer and keeps that customer history or a project is used as a running sprint planning tool.

If 1500 issues are too many for Gantt OnDemand, that is unfortunately a showstopper for us.

Christian, archiving works *only* for chart rendering and has nothing to do with the rest of JIRA system. Projects and issues will still be there. As you now deselecting almost 40 projects when working with Gantt OnDemand, so I assume, you don't really need to have access to these (presumably already completed) projects and they can be safely archived. That way, you can work only with projects you want.

This too is a showstopper. The default should be all projects un-selected and not have to be archived.

Adding my vote for a basic change.

Having all project selected for the first run is not a big issue, I think. You can unselect unwanted projects and forget about them as all filter settings are remembered and next time you open the plugin page only projects you have chosen before will be selected.

There is a suggestion however, to select by default only the JIRA's "current project" which, I guess, might be a middle ground here.

Having all project selected for the 1st run is not a big issue: It is a big issue. See next question.

Are the configuration settings maintained per user?

I would then adamantly insist that the initial view (1st run) have all of the visible projects unchecked. This would avoid the long delay in cases like mine and I suspect others. Each project lead can then 'check' the projects of interest which will then be the default for them.

Hi Adrian, I am aware of that, but we will still have maybe 30 ongoing projects with around 1.000 issues as of today, and they cannot be archived from a gantt perspecttive either, since each project is dedicated to each ongoing customer relation. Also wasn't aware of the 4.000 issues hardstop. We are currently expanding the company and will hopefully reach the limit of 4.000 open or closed issues across 50 open projects within a year.

Agreed with this. We have 15 active projects and well over 5000 issues spanning across them. Sometimes, we have dependencies between projects, too, so we can't simply "turn off" things. We really need a better way of creating project charts, such as based on a common label spanning projects or a filter query or Sprint(s) or something, with the ability to save and share those criteria like filters or dashboards.

Any update on this request to address the long loading time and restrictive limits?

Hi Jim,

There is still a limit of issues (5000 for now) that can be rendered on the chart simultineusly. We have plans to review the Add-on performance but can't give you any dates yet.

You have to be aware however, that chart rendering is 80% frontend (JavaScript) task so the performance may vary depending on your browser and computer hardware setup.


I understand that the front-end may play into this but the ability to have the plug-in start with NO projects checked would have helped immensely. There are other comments where this request would have been useful.

You are right, it's been suggested already to not include any projects by default so I decided to add that into the Roadmap:

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,737 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you