-
Bug
-
Resolution: Fixed
-
High
-
7.4.17, 7.13.2, 7.13.4, 7.14.2
-
None
-
29
-
Severity 2 - Major
-
55
-
The fix for this bug will be released to our Long Term Support release.
The fix for this bug has been approved for backport and will be available in an upcoming 7.13 and 7.19 releases of Confluence. Check the fix-version field for details.
Confluence takes a long time to open the editor when editing pages with lots of JIRA issues macros using the total issue count.
The CPU also spikes for a brief time during the editor loading time.
How to replicate
- JIRA 8.13.5
- Confluence 7.13
1) Create a project on JIRA and add a few issues (2 for example).
2) Set the application links between Confluence and JIRA
3) Create a new page in Confluence and add a JIRA issue macro using the project created on number 1 above.
4) On the JIRA macro display options, select the total issue count display.
5) Save the page.
Editing the page with a single issue works fine. However, as we add more and more JIRA macros to the page with the "total issue count", the editor becomes slower each time.
Disabling the collaborative editor does not help.
The issue happens with simple and complex JIRA macro filters.
Observed results
Editing the same page with more JIRA macros produced the following results:
1) Page with 10 JIRA issues = 5 seconds
2) Page with 50 JIRA issues = 8 seconds
3) Page with 100 JIRA issues = 12.6 seconds
4) Page with 250 JIRA issues = 19.5 seconds
As the number of issues on a page increases, the time to edit also continues increasing.
This HAR shows the behavior when loading the editor:
Expected behavior
Confluence should open the page editor faster.
Workaround
From Confluence 7.8.1 onward the dark features confluence.extra.jira.edit.ignore.count can be used to reduce the impact of this issue. With this dark feature enabled, Confluence will not attempt to load issue counts, and instead will display "x" in edit mode instead.
Notes
During tests, it was observed that changing the JIRA macro display mode to table renders the edit page really fast (under 5 seconds), even when using 250 JIRA macros on the same page.
The behavior seems tied to the total issue count display mode.
- is related to
-
-
- Closed
-
-
PS-109123 You do not have permission to view this issue
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
![[Atlassian Documentation] Page](https://confluence.atlassian.com/images/icons/favicon.png "[Atlassian Documentation] Page"){kind=icon}
[CONFSERVER-74871] Edit pages with a lot of JIRA issues macros using "total issue count" takes a long time
A fix for this issue is available in Confluence Server and Data Center 7.19.15.
Upgrade now or check out the Release Notes to see what other issues are resolved.
in case anyone's interested, we applied that dark feature-based workaround 3 months ago and I can confirm it worked well, as detailed above. (on latest versions.)
Hey All,
A quick update.
As 8f4050917dd7 mentioned, we do have a workaround for this one. I've added it to the main issue.
Please let us know how you get on with using it. I'll add this to our backlog for now.
Thanks,
James Ponting
Engineering Manager - Confluence Data Center
I have a similar issue (see https://support.atlassian.com/requests/PS-109123/) that appears to be related to this, but instead of having a problem with long delays opening the editor (well, I have those too 
), I have a problem with extremely long delays for REST API completion when writing the Confluence page containing all these macros. The page is available to view very soon after issuing the REST API call to write the page, but the REST API completion doesn't happen for a looooooong time afterward.
I'm surprised nobody from Atlassian suggested this old workaround I found in CONFSERVER-44664:
- Starting from versions 7.8.1 and 6.13.18, in the dark features, we would need to add "confluence.extra.jira.edit.ignore.count" to prevent Confluence from making requests to Jira. Due to that change, instead of a real count number, we will see "x" in edit mode.
Works for me on 7.16.4
Hi. We also getting the same issue on 7.13.7. We have tried increasing the timeout but seems to have not affect.
@Rodrigo: were you able to test any older versions of Confluence to see if this recurs there?
@fabric-tools, do you by chance know what version of Confluence you were on previously where you did not have this issue?
As it seems to be only reported in 7.13 and 7.14, this sounds like a regression, which I would hope means that it wouldn't be as hard to fix?
I agree with the previous comment and the suggestion to not require all Jira macro's on the page to first be rendered when you select 'Edit'. We have been dealing with this same issue for a long time as well. Our development teams have summary pages with large tables and multiple 'Jira/Issue Filter' macros showing the total number of Jira issues.
One table has 24 such macros. Another table has 3 macros, all set to 'Total Issue Count' for monitoring the number of issues reported against multiple software versions.
The page takes 2 minutes: 45 seconds to allow for editing.
If I change all macros to display as a 'Table' the page now takes only 35 seconds to allow editing but this is not a practical way to display as they really just want to see the sum total of issues but also have the ability to select any macro which will then take them to the list of issues meeting that specific criteria.
I wanted to see if there was another macro that could be used to pull in Jira information but the only one I see available is the 'Jira Chart' macro. I tried that using a 'two-dimensional' table. The results is more usable than the Jira Issue/Filter' macro but there are trade-offs. Now edit time is still around 33 seconds (far less than the original) for the page but save/refresh time goes to 1 min. 20 seconds.
We are on JIRA version 8.5.1, Confluence version 7.13.2
Reference Confluence ticket CSP-302624.
This issue is killing us with our Jira integration. We have been on a very old version of Confluence for some time (not on purpose) and we recently finally got to upgrade it and now teams that use these Jira macros can't edit their pages anymore. These pages have hundreds of queries per page and some of these queries return nearly a million issues.
Why doesn't Confluence simply buffer this, or just simply NOT render the macro when editing? What purpose does this serve? Why not just render it as a simple placeholder for the Jira macro, and not return the results?
A fix for this issue is available in Confluence Data Center 8.6.0.
Upgrade now or check out the Release Notes to see what other issues are resolved.