|
Most of the slowness is from checking whether the current user has permission to see the page or not. This involves checking both the Space Permissions and Page Restrictions. The Space Permission checks can be particularly costly and are not cached, even during the request.
So the next question based on that would be, why aren't at least the space permissions cached during the request?
This issue is starting to hit us hard, we have pages that end up checking permissions over 500 times and caching only saves the second person to view the data within the refresh window. Like the above respondent, we see response times in the tens of seconds for some pages. Hi Tony,
There's no good reason not to cache them during the request. We just haven't implemented it yet. Thankyou for voting for this issue. Cheers, There are several other issues related to this same problem as well. We are experiencing very slow load times on a Space with 1000 child pages.
It may make sense to combine all of these into one larger support issue? I know this problem has limited our ability to roll Confluence out to the rest of our users who want a separate page per customer. Here are the other Issues I know of related to this: https://support.atlassian.com/browse/CSP-16926 are related to slow performance on spaces with a lot of child pages thanks! What version(s) does this affect? We are on 2.8.2 with a fairly large install and are seeing some chronic performance problems that could be related. Our 'Space Permissions' cache is listed as 98% effective.
Hi, this affects all versions of Confluence. It should be improved somewhat in Confluence 2.10 by
We should implement an exists() method on the DAO and the PageManager. This is all what the link renderer needs. Once that is done we can optimize that method to not load whole page objects. And we could use the internal sapcekey/title -> id cache. If there is an entry for a spacekey/title combination we can just return true.
Could we talk to the index for this?
Alternatively, could we do a two-pass system, where we find out all the links we want to link to, and ask for them in one database query, and parse the results? Should be faster than multiple db queries. The permissions checking no longer shows up in our profiling. Rather, the majority of the time in link rendering is spent determining whether page exists.
We'll be implementing Chris's suggested fix for the next major release of Confluence. @Scott:
The thing with the lucene index in Confluence is that it is only updated once every minute. That way you might end up with links not being rendered just because the index queue is not flushed (for example if you create a new page and link to it on some other page straigt away). I've tested with 500 child pages and either the {children} macro or a list of links on the parent page, using Confluence standalone with HSQL. There's no significant difference between 2.10.1 and 3.0. In both cases, primed page and permission caches help reduce the time from 14 seconds to 1.5 seconds.
I'm going to test further with a larger data set to see if there's some aspect of scale I'm not examining in my current test (like, say, having a huge number of rows in the CONTENT table). I'd like to be able to reproduce the problem in 2.10 – at the moment it seems like this is just a deficiency in the size of the cache. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Improve page load time when it contains lots of links
What about a page directive that says "Assume all links exist". This could drammatically improve rendering time.
I am finding that a page with 1500 children, and containing links to all the children, takes over 3 minutes to render, despite the fact that the wikitext is only about 60K.
Another work around might be to change the links to the other pages into external links back to the wiki. That might avoid the database lookup. Of course you'd loose features like rename, and "what pages link to this page" type features.