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

Improve the way the Backlog is loaded for better performance and/or rendering of a large number of items

XMLWordPrintable

    • 21
    • 37
    • Hide
      Atlassian Update – 21 December 2018

      Dear Jira users,

      We’re glad to announce that this issue will be addressed in our upcoming 8.0 release.

      You can find more details about our 8.0 beta release here — https://community.developer.atlassian.com/t/beta-for-jira-8-0-is-up-for-grabs/25588

      Looking forward to your feedback!

      Kind regards,
      Syed Masood
      Product Manager, Jira Server and Data Center

      Show
      Atlassian Update – 21 December 2018 Dear Jira users, We’re glad to announce that this issue will be addressed in our upcoming 8.0 release. You can find more details about our 8.0 beta release here — https://community.developer.atlassian.com/t/beta-for-jira-8-0-is-up-for-grabs/25588 Looking forward to your feedback! Kind regards, Syed Masood Product Manager, Jira Server and Data Center
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Software Server. Using JIRA Software Cloud? See the corresponding suggestion.

      Problem Definition

      When there are many issues on the board, the load time is pretty bad.

      Edit: incorporating performance for epics and versions

      Suggested Solution

      We could 'paginate' the results to improve the experience for example. Ie. Once a user scrolls down, we can load the other issues which are ranked below the bottom of the screen.

      Notes
      • Agile pefromance logging - you can enable DEBUG for com.atlassian.greenhopper.performance which will give you breakdown for slow request, example of output: 
        /// Full line: 2018-06-13 21:59:20,824 ... /rest/greenhopper/1.0/xboard/plan/backlog/data.json [com.atlassian.greenhopper.performance

2018-06-13 21:59:20,824 ... /data.json [com.atlassian.greenhopper.performance] SearchProvider.search  8ms
2018-06-13 21:59:20,841 ... /data.json [com.atlassian.greenhopper.performance] SearchProvider.searchAndSort  13ms
2018-06-13 21:59:20,841 ... /data.json [com.atlassian.greenhopper.performance] collectIssues (search and callback)   15ms
2018-06-13 21:59:20,841 ... /data.json [com.atlassian.greenhopper.performance] collectIssues (callback only) 8ms
2018-06-13 21:59:20,844 ... /data.json [com.atlassian.greenhopper.performance] SearchProvider.search  2ms
2018-06-13 21:59:20,850 ... /data.json [com.atlassian.greenhopper.performance] SearchProvider.searchAndSort  2ms
2018-06-13 21:59:20,850 ... /data.json [com.atlassian.greenhopper.performance] collectIssues (search and callback)   3ms
2018-06-13 21:59:20,850 ... /data.json [com.atlassian.greenhopper.performance] collectIssues (callback only) 1ms
2018-06-13 21:59:20,852 ... /data.json [com.atlassian.greenhopper.performance] SearchProvider.search  1ms
2018-06-13 21:59:20,862 ... /data.json [com.atlassian.greenhopper.performance] SearchProvider.search  1ms
        • note: collectIssues (callback only) 8ms

            [JSWSERVER-9920] Improve the way the Backlog is loaded for better performance and/or rendering of a large number of items

            Mark Finta added a comment -

            @Sed you don't need to create extra projects to accomplish what Martin Jopson suggested.  All he is saying you do is create more than one board in the current project.  When you create a project, it automatically creates one type of board for you but you can create as many boards as you want for the project.  Atlassian has plenty of documentation and there are plenty of youtube videos that show you how to set this up. https://www.youtube.com/results?search_query=create+jira+bords

             

            Mark Finta added a comment - @Sed you don't need to create extra projects to accomplish what Martin Jopson suggested.  All he is saying you do is create more than one board in the current project.  When you create a project, it automatically creates one type of board for you but you can create as many boards as you want for the project.  Atlassian has plenty of documentation and there are plenty of youtube videos that show you how to set this up. https://www.youtube.com/results?search_query=create+jira+bords  

            Sed added a comment -

            From reading previous statements, what you are suggesting is that Product Owners of Backlogs with (in our example: 2000+ items) create 5-10 additional projects and then go through each project to determine the priority of what is to be taken into the next release and then MOVE the items into a primary project and then re-organize the items there once again and pull them into a release/iteration? 

            Can we get someone to walk us through how to accomplish this with our teams? I just don't see this happening.

            With no numbering on the Backlog on top of poor performance with larger Backlogs, I really don't see how this hasn't been raised as a higher concern. 

            Sed added a comment - From reading previous statements, what you are suggesting is that Product Owners of Backlogs with (in our example: 2000+ items) create 5-10 additional projects and then go through each project to determine the priority of what is to be taken into the next release and then MOVE the items into a primary project and then re-organize the items there once again and pull them into a release/iteration?  Can we get someone to walk us through how to accomplish this with our teams? I just don't see this happening. With no numbering on the Backlog on top of poor performance with larger Backlogs, I really don't see how this hasn't been raised as a higher concern. 

            Martin (Inactive) added a comment -

            tcenl - as noted the boards are optimised for a smaller number of issues than it appears you are using.
            As a workaround you could split the total issues into a number of boards for planning purposes, which will be faster to load and do epic assignments etc, then have another board including all the issues which can be used for statistics.

            Kind regards,
            Martin
            JIRA Software

            Martin (Inactive) added a comment - tcenl - as noted the boards are optimised for a smaller number of issues than it appears you are using. As a workaround you could split the total issues into a number of boards for planning purposes, which will be faster to load and do epic assignments etc, then have another board including all the issues which can be used for statistics. Kind regards, Martin JIRA Software

            Azfar Masut (Inactive) added a comment - - edited

            It is good to see that a feature request is available that addresses the performance issues with the Jira Boards.

            However, as indicated (https://jira.atlassian.com/browse/JSW-10976), the board feature was never intended to be used with a large number of issues. Still, having a lot of issues is a reality for our projects. We have enough issues to feed the development teams with well over a year of work, and in order to get some grip on the future we would like to incorporate all previous issues into the statistics so that we can give estimates that are based on a decent amount of evidence.

            Restricting the number of issues that are displayed on the boards by adjusting the filters that apply to the board immediately has impact on the statistics that are reported by that board: issues that are excluded by the filters do not contribute to the statistics of the board (which, in a way, makes sense).
            We would like to handle this large amount of issues. With this long list (i.e. more than 500 issues) we would like to schedule epics, assign stories to backlogs, assign stories to sprints and we still would like to be able to respond to the ever changing demand of customers and day by day work and have an overview of all the work that lies ahead of us.

            This doesn't necessarily have to be done on one page / board / etc., but somehow we need to control this large amount of issues.
            Can you tell us how Atlassian has envisioned such a workflow within Jira? Or point us to a source that describe how one should do this?

            Regards,
            Jeroen Kouwer
            tcenl

            Azfar Masut (Inactive) added a comment - - edited It is good to see that a feature request is available that addresses the performance issues with the Jira Boards. However, as indicated ( https://jira.atlassian.com/browse/JSW-10976 ), the board feature was never intended to be used with a large number of issues. Still, having a lot of issues is a reality for our projects. We have enough issues to feed the development teams with well over a year of work, and in order to get some grip on the future we would like to incorporate all previous issues into the statistics so that we can give estimates that are based on a decent amount of evidence. Restricting the number of issues that are displayed on the boards by adjusting the filters that apply to the board immediately has impact on the statistics that are reported by that board: issues that are excluded by the filters do not contribute to the statistics of the board (which, in a way, makes sense). We would like to handle this large amount of issues. With this long list (i.e. more than 500 issues) we would like to schedule epics, assign stories to backlogs, assign stories to sprints and we still would like to be able to respond to the ever changing demand of customers and day by day work and have an overview of all the work that lies ahead of us. This doesn't necessarily have to be done on one page / board / etc., but somehow we need to control this large amount of issues. Can you tell us how Atlassian has envisioned such a workflow within Jira? Or point us to a source that describe how one should do this? Regards, Jeroen Kouwer tcenl

            TPE added a comment -

            Thanks for the suggested workaround. However it does not work in our configuration.
            In our case with JIRA 6.2.7 and JIRA Agile 6.6.80 this workaround reduces the issues in the filter from 2778 to 961, but the performance is even slower than before.

            TPE added a comment - Thanks for the suggested workaround. However it does not work in our configuration. In our case with JIRA 6.2.7 and JIRA Agile 6.6.80 this workaround reduces the issues in the filter from 2778 to 961, but the performance is even slower than before.

            Mohamed Gargouri added a comment -

            A workaround is to apply this JQL query for your board filters:

            (project = "PROJECT_NAME" AND Sprint in openSprints()) OR (project = "PROJECT_NAME" AND status != Closed AND Sprint not in openSprints()) OR (project = "PROJECT_NAME" AND status != Closed AND Sprint is EMPTY)

            It will prevent loading issues that are never displayed on your board.

            Mohamed Gargouri added a comment - A workaround is to apply this JQL query for your board filters: (project = "PROJECT_NAME" AND Sprint in openSprints()) OR (project = "PROJECT_NAME" AND status != Closed AND Sprint not in openSprints()) OR (project = "PROJECT_NAME" AND status != Closed AND Sprint is EMPTY) It will prevent loading issues that are never displayed on your board.

            Csaba Vertessy added a comment -

            We are having this issue with the v6.2.7 too.

            +1 for Citrix Devops for the workaround.

            Csaba Vertessy added a comment - We are having this issue with the v6.2.7 too. +1 for Citrix Devops for the workaround.

            intersol_old added a comment -

            What is not specified here is that the core problem is that the board filter must include all the historical issues in order to be able to generate the reports properly. If you put only the unresolved issues in it, the performance problem is solved with planning, but reports are damaged, Also the WORK tab would be affected because dragging issues into last column (done) would make them disappear.

            The issue is presented in more details here https://answers.atlassian.com/questions/8620924/how-to-make-agile-board-planning-loading-to-a-decent-performance-level – be sure you read all comments.

            My impression is that the correct solution for this is to add two automatic filters:

            • for PLAN mode, do add "Resolution = Empty" to the filter query (so the tons of issue would not reach the client)
            • for WORK mode to add Sprint = xxx (or something similar), so it would also be really fast.
            • for REPORT mode, to do nothing yet, as this one really needs tons of issues to do reporting on. Still it would be wise to test the performance with a 10-20k issue filter. People didn't report speed issues with reporting, or at least not yet.

            intersol_old added a comment - What is not specified here is that the core problem is that the board filter must include all the historical issues in order to be able to generate the reports properly. If you put only the unresolved issues in it, the performance problem is solved with planning, but reports are damaged, Also the WORK tab would be affected because dragging issues into last column (done) would make them disappear. The issue is presented in more details here https://answers.atlassian.com/questions/8620924/how-to-make-agile-board-planning-loading-to-a-decent-performance-level – be sure you read all comments. My impression is that the correct solution for this is to add two automatic filters: for PLAN mode, do add "Resolution = Empty" to the filter query (so the tons of issue would not reach the client) for WORK mode to add Sprint = xxx (or something similar), so it would also be really fast. for REPORT mode, to do nothing yet, as this one really needs tons of issues to do reporting on. Still it would be wise to test the performance with a 10-20k issue filter. People didn't report speed issues with reporting, or at least not yet.

              tjoy Tilwin Joy (Inactive)
              ayakovlev@atlassian.com Andriy Yakovlev [Atlassian]
              Votes:
              86 Vote for this issue
              Watchers:
              73 Start watching this issue

                Created:
                Updated:
                Resolved: