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; } } }

Very slow Gantt OnDemand - are we doing it wrong?

Christian Triantafillou Schade

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?

regards

Christian

Accepted answers

Adrian Wieczorek

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?

All comments

Adrian Wieczorek

Christian Triantafillou Schade

Yes, please hava look at https://rubiqsoft.atlassian.net/

Adrian Wieczorek

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:

https://wisoft.atlassian.net/wiki/display/GanttOnDemand/Configuration

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.

Christian Triantafillou Schade

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.

Adrian Wieczorek

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.

Christian Triantafillou Schade

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.

Jim Gilbert

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.

Adrian Wieczorek

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.

Chris Verges1

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.

Jim Gilbert

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

Adrian Wieczorek

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.

Jim Gilbert

Adrian,

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.

Adrian Wieczorek

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

https://wisoft.atlassian.net/browse/GANTT-161

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-cloud