-
Suggestion
-
Resolution: Fixed
-
None
When an RSS Feed is requested, Confluence renders all pages into the resulting XML.
This can be computationally intensive for certain macros, especially the SQL Macro.
If people are subscribed to wide-ranging feeds such as 'New Pages' or 'Changed Pages', this can cause many such pages to render. Many of these rendering passes are for no benefit to humans, since RSS Readers refresh feeds on a regular basis, especially Google Reader which refreshes every 30 minutes even if nobody is currently using Google Reader!
Further, the feeds cannot be cached because they are dependent upon each individual user's security privileges.
The result: Goole Reader refreshes the feed 48 times a day, causing computationally intesive pages to render for no human benefit, and it does this for every separate user who has subscribed. Other RSS Readers update less frequently, but still annoyingly.
Recommendation: Do not render the SQL macro in RSS Feeds. There may also be other macros that are best avoided. (Perhaps a flag in the plugin that indicates whether to render in RSS Feeds?)
It is especially the case on Atlassian's own Extranet that this causes high load.
- is duplicated by
-
CONFSERVER-19537 HTTP requests are occasionally considered to be RSS requests by the blacklisting mechanism in renderer
-
- Closed
-
- is related to
-
-
- Closed
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFSERVER-18180] RSS Feeds: Do not render computationally intensive macros in RSS Feeds due to frequent rendering to RSS Readers
Changes to address this problem were committed and shipped in 3.2 without review . Does this issue still require further improvement? Please re-open if so.
The simplest way to implement this is checking the render mode inside the macro and changing the output.
Note that we've had issues raised in the past when certain macros didn't render in some circumstances (CONF-4655, CONF-8222), so this should probably not be the default behaviour, but rather an admin feature that can be configured if required.
Update: a better approach would be to execute macro rendering asynchronously with a limit on how long it can execute for. This wouldn't stop memory usage problems due to the SQL macro (in truth, nothing really can), but it would help with thread or CPU usage problems.
To use this undocumented feature, create a Bandana entry in the global context with key "blacklistedRssMacros" whose value is a list of macro commands that are blacklisted for RSS.