Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-45903

Adding a new worklog entry is slow due to a large change history

    XMLWordPrintable

Details

    • 6.04
    • 116
    • Severity 2 - Major
    • 149
    • Hide
      Atlassian Update – 31 May 2023

      Dear Customers,

      Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog.

      The workaround for this bug is as follows:
      Clone the problematic issues with long history and use the cloned issues to log work

      Please continue watching this ticket for future updates and changes in the timeline that impacts your work.

      Best regards

      Jakub Reczycki

      Jira DC Developer

      Show
      Atlassian Update – 31 May 2023 Dear Customers, Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog. The workaround for this bug is as follows: Clone the problematic issues with long history and use the cloned issues to log work Please continue watching this ticket for future updates and changes in the timeline that impacts your work. Best regards Jakub Reczycki Jira DC Developer

    Description

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

      Performing some testing with JIRA 6.4.5, I've noticed that there is a huge difference when logging work on an issue with no history and on an issue with a long history.

      I enabled Profiling on JIRA to check the difference:

      Example 1: Issue with 858 entries on history:

      2015-10-21 15:18:53,596 http-bio-8080-exec-21 DEBUG sysadmin 918x163x1 1zsbpp 0:0:0:0:0:0:0:1 /secure/CreateWorklog.jspa [atlassian.util.profiling.UtilTimerStack] [6104ms] - /secure/CreateWorklog.jspa
      [0ms] - PermissionManager.hasPermission()
      [6100ms] - CreateWorklog.execute()
      [1ms] - PermissionManager.hasPermission()
      [1ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [44ms] - IssueIndexManager.reIndexIssueObjects()
      [1ms] - PermissionManager.hasPermission()
      [11ms] - IssueIndexManager.reIndexWorklogs()
      

      Example 2: Issue with 4 entries on history:

      2015-10-21 15:21:44,662 http-bio-8080-exec-24 DEBUG sysadmin 921x169x1 1zsbpp 0:0:0:0:0:0:0:1 /secure/CreateWorklog.jspa [atlassian.util.profiling.UtilTimerStack] [189ms] - /secure/CreateWorklog.jspa
      [0ms] - PermissionManager.hasPermission()
      [186ms] - CreateWorklog.execute()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [0ms] - PermissionManager.hasPermission()
      [37ms] - IssueIndexManager.reIndexIssueObjects()
      [0ms] - PermissionManager.hasPermission()
      [9ms] - IssueIndexManager.reIndexWorklogs()
      [1ms] - PermissionManager.getProjects()
      

      Notes

      It further degrade the performance of the instance and it takes longer to load issues with large history items

      • SQL to identify issues with large worklog history:
        select issueid, count(id) from worklog group by issueid having count(id) > 100 order by (count(id)) desc;
        
        • With join
          select concat(p.pkey,'-',i.issuenum) as issue, count(a.id) from worklog a, jiraissue i, project p where i.project = p.id and i.id = a.issueid group by p.pkey,i.issuenum having count(a.id) > 100 order by count (a.id) DESC;
          
      • SQL to find large number of jiraaction (comments ... ) per issue:
        select a.issueid, count(a.id) from jiraaction a group by a.issueid order by count (a.id) DESC;
        
        • With join
          select concat(p.pkey,'-',i.issuenum) as issue, count(a.id) from jiraaction a, jiraissue i, project p where i.project = p.id and i.id = a.issueid group by p.pkey,i.issuenum order by count (a.id) DESC;
          

      Workaround

      Clone the problematic issues with long history and use the cloned issues to log work

      Attachments

        1. 27.jpg
          2.40 MB

        Issue Links

          Activity

            People

              815943ed5f89 Olga Springer
              rrosa@atlassian.com Rodrigo Rosa
              Votes:
              167 Vote for this issue
              Watchers:
              152 Start watching this issue

              Dates

                Created:
                Updated: