Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-13194

UnreleasedVersions() is slow on large instances

XMLWordPrintable

      Summary

      Loading time for Kanban board with default work subfilter is longer.
      Default work subfilter with UnreleasedVersions():

      fixVersion in unreleasedVersions() OR fixVersion is EMPTY

      Calls to /rest/greenhopper/1.0/xboard/work/allData.json are more slow with default work subfilter.

      Environment

      • Instances with large number of Versions are affected, example: 10k+

      Steps to Reproduce

      1. Load board

      Expected Results

      Loading board doesn't degrade with number of version in other project (in whole JIRA)

      Actual Results

      Loading board takes longer when there is a higher number of version in other project (in whole JIRA).

      Notes

      See related KB: Kanban board loading is slow

      Some improvements have already been done in GHS-9611, JRA-38883, JRASERVER-62666

      Original data from user

      Here are some system stats

      Total versions: 23792
Of the total, 20616 are *unreleased*.

JIRA issues: 1.5 million
Projects: 660

      Here's a before and after load time in seconds when we delete the work subfilter:

      11.7050  https://jira/rest/greenhopper/1.0/xboard/work/allData.json 
11.3350  https://jira/rest/greenhopper/1.0/xboard/work/allData.json 

--- delete work subfilter ---

3.0680  https://jira/rest/greenhopper/1.0/xboard/work/allData.json 
3.1440  https://jira/rest/greenhopper/1.0/xboard/work/allData.json 
3.0290  https://jira/rest/greenhopper/1.0/xboard/work/allData.json 
3.1320  https://jira/rest/greenhopper/1.0/xboard/work/allData.json

      Workaround

      • Delete Kanban board sub-filter if you don't need versions
      • If you need version, add specific project(s) related to JQL filter for the board into unreleasedVersions function 
        fixVersion in unreleasedVersions(ProjA, ProjB) OR fixVersion is EMPTY

            [JSWSERVER-13194] UnreleasedVersions() is slow on large instances

            Ilya Zinoviev (Inactive) added a comment - - edited

            Hi everyone!
            I'm glad to announce that we've made a significant progress regarding performance of unreleasedVersions().
            We've resolved following issues during our work on Jira 8.4:

            We believe these fixes will address majority of causes for the described problem. As this issue is pretty broad we are closing this issue. If you keep witnessing the problem please comment on this ticket or create a new one describing your specific case

            –
            Ilya Zinoviev
            Jira Development

            Ilya Zinoviev (Inactive) added a comment - - edited Hi everyone! I'm glad to announce that we've made a significant progress regarding performance of unreleasedVersions() . We've resolved following issues during our work on Jira 8.4: https://jira.atlassian.com/browse/JRASERVER-69009 https://jira.atlassian.com/browse/JSWSERVER-16401 We believe these fixes will address majority of causes for the described problem. As this issue is pretty broad we are closing this issue. If you keep witnessing the problem please comment on this ticket or create a new one describing your specific case – Ilya Zinoviev Jira Development

            Andriy Yakovlev [Atlassian] added a comment -

            venkateshwar.aynala
            Thanks for sharing your observation and Jira stats.

            To answer your question:

            sub-filter can be amended at the backend to include the project key

            You can update the tables directly and restart Jira, but since you would need to add the unique project key (which you would need to identify first) to subQuery, that would be pretty much the same amount of work.

            Sorry.

            Andriy Yakovlev [Atlassian] added a comment - venkateshwar.aynala Thanks for sharing your observation and Jira stats. To answer your question: sub-filter can be amended at the backend to include the project key You can update the tables directly and restart Jira, but since you would need to add the unique project key (which you would need to identify first) to subQuery, that would be pretty much the same amount of work. Sorry.

            Venkateshwar Aynala added a comment -

            This issue appears to be affecting us also.

            Jira server version 7.6.8

            We've had a number of very slow loading boards that have been fixed by adding the project key to the boards sub-filter.

            Our instance has 1.9m Issues and 2100 Projects.

            Other than editing each individual boards sub-filter is there a way that that the sub-filter can be amended at the backend to include the project key?

            Venkateshwar Aynala added a comment - This issue appears to be affecting us also. Jira server version 7.6.8 We've had a number of very slow loading boards that have been fixed by adding the project key to the boards sub-filter. Our instance has 1.9m Issues and 2100 Projects. Other than editing each individual boards sub-filter is there a way that that the sub-filter can be amended at the backend to include the project key?

            Gonchik Tsymzhitov added a comment -

            Hi!

            it is also, affected for 7.6.10 version

            Cheers,
            Gonchik Tsymzhitov

            Gonchik Tsymzhitov added a comment - Hi! it is also, affected for 7.6.10 version Cheers, Gonchik Tsymzhitov

            Raul Pelaez added a comment -

            I agree with Matt,

             

            We have the same issue, in our large instance, we have about 4000 versions (3500 archived) in each project (we have about 300 projects).

            We don't want to modify the source code/files of Jira to change the default subfilter query of the boards. 
            We want to avoid the message of error when the users create new Kanban boards. It's a little bit annoying and it's a very bas experience for new users.

            I know that we have a lot of versions... ,but for me this is a clear bug of Jira.
            For Jira there is no limit of versions, right?

             

            Regards

            Raul Pelaez added a comment - I agree with Matt,   We have the same issue, in our large instance, we have about 4000 versions (3500 archived) in each project (we have about 300 projects). We don't want to modify the source code/files of Jira to change the default subfilter query of the boards.  We want to avoid the message of error when the users create new Kanban boards. It's a little bit annoying and it's a very bas experience for new users. I know that we have a lot of versions... ,but for me this is a clear bug of Jira. For Jira there is no limit of versions, right?   Regards

            MattS added a comment -

            I find that a more useful subfilter for many Kanban boards is:

            status not in (closed, resolved, completed) or resolutiondate > -2w

            This ignores the idea of artificially creating versions just so you can hide issues. Instead it shows everything that isn't done, or was done in the last few weeks

            MattS added a comment - I find that a more useful subfilter for many Kanban boards is: status not in (closed, resolved, completed) or resolutiondate > -2w This ignores the idea of artificially creating versions just so you can hide issues. Instead it shows everything that isn't done, or was done in the last few weeks

              izinoviev Ilya Zinoviev (Inactive)
              a38518e05741 David Yu
              Affected customers:
              35 This affects my team
              Watchers:
              36 Start watching this issue

                Created:
                Updated:
                Resolved: