Understanding report caching

Starting with version 6.17.0 of Reporting for Confluence, a new feature to cache the report output has been introduced. The Report caching feature is disabled by default and must be enabled from the Reporting Admin Config by an admin.

Once enabled, all reports with result types of content (pages, blog posts, attachments, comments,...), spaces, and users will be written to the “ServiceRocket Reporting Cache” after the first render. Then, all subsequent renders of the same report will be loaded from the cache until the time-to-live (TTL) expires after 24 hours by default.


Pros and Cons of report caching

ProsCons
  • Once cached, even very large reports render almost instantly (refer to the performance comparison below).
  • Rendering reports from the cache removes the stress on the system’s resources.
  • Caching in a cluster is replicated across all nodes. Users will always get hot caches on any node even if the cached report was written on a different node.
  • User permissions are maintained and honored. An admin user group with access to more results in a report will have a separate output cache than that of a regular user group. Furthermore, revoked permissions for a user will invalidate their cached reports immediately ensuring they don’t continue to see what they don't have access to anymore.
  • Extremely large reports that cause page render timeout errors during page view can now be constructed and cached in the background then become available immediately on page revisit.
  • Data freshness with calculated values inside the report (not page) will not be updated until the TTL expires. For example, using the Data Supplier will only fetch the Scaffolding data values on the first load and won’t update the values until the cached report expires.

Notes

The freshness of data concerns are mitigated because fresh data will be used and the cache will be invalidated if:

  • Query results change. E.g. new pages are created affecting the total results number or permissions are changed affecting what users have access to.
  • Any storage format changes for the report. This includes changing the parameters or the body of the reporting macros as well as changing the report sorting or filtering macros.

Flushing Reporting cache

Usually, the cache will expire after the TTL expires and the report output data will automatically refresh and renew. However, occasionally, it may be required to flush the cache manually. In that scenario, you can flush the cache for:

  1. Individual Reports: Change the value of any parameter in the report. Alternatively, edit the body of any of the macros in the report. This will create a new cache key for the report enabling new data to be fetched and cached.
  2. All Reports: System admins can use the flush cache button on the Reporting Admin Config page.

Optimizing Reporting cache

By default, Reporting cache has a size of 1,000 entries with a TTL of 24 hours. While this default configuration is good for most medium-sized instances, it is not one size fits all. Both the TTL and cache sizes can be configured and changed if needed. Refer to Atlassian’s cache performance tuning guide for general tips on fine-tuning the cache configuration. Additionally, consider:

  1. Longer TTL may benefit from larger cache sizes.
  2. A larger cache size may consume more memory, only increase if required.
  3. Review the cache hit / miss / eviction ratios for “ServiceRocket Reporting Cache” from "<base-url>/admin/cache/showStatistics.action#fullView" to determine best values for your instance.

Debugging Reporting cache

You can enable the debug logs to view the Reporting performance logs and watch the report caching in action. To do so, follow these steps:

  1. Enable performance logging.
  2. Watch the logs for:
    1. 'Cache miss!': When rendering the report for the first time.
    2. 'Cache Write!': Following the previous log to add a new cache entry.
    3. 'Cache hit!': Upon viewing the same report again before the TTL expires.

Performance comparison

These results were collected on a Confluence 7.19.1 instance with just over 1,000 spaces and 5,000 users. The rendering time data was for a Report Table with 5 columns each using a Report Info for output with Link to Item. Each reading was taken at least twice and averaged. 

These performance metrics are not meant as absolute benchmarks of expected performance but more as a relative measure of the expected performance gains when caching is enabled.

Report on Pages

These results were collected from space with just over 5,000 pages.

Cache Performance with Report on Pages

Results Count

Disabled

Enabled - Miss

Enabled - Hit

1

0.20

0.36

0.01

100

1.20

1.17

0.01

1000

12.27

13.75

0.01

2500

49.20

53.66

0.01

4000

104.49

104.03

0.01

5000

160.83

155.87

0.01

Report on Users

These results were collected from an instance with just over 5,000 users.

Cache Performance with Report on Users

Results Count

Disabled

Enabled - Miss

Enabled - Hit

1

0.08

0.08

0.01

100

1.13

1.19

0.01

500

6.28

6.23

0.01

1000

14.29

15.25

0.01

2500

55.19

53.16

0.01

5000

193.93

189.59

0.01

Report on Space

Cache Performance with Report on Spaces

Results Count

Disabled

Enabled - Miss

Enabled - Hit

1

0.07

0.05

0.01

10

0.32

0.18

0.01

100

1.84

1.29

0.01

500

7.01

6.21

0.01

1000

12.66

12.11

0.01