Database Reference
In-Depth Information
Once a report is configured to be rendered from a report snapshot,
subscriptions can then be configured to execute every time an updated
snapshot is created.
Caching
The caching feature is very similar to snapshots in that it exists as a mechanism to
improve report processing performance by keeping a stored copy of the report data
and structure from which subsequent requests can be generated without having
to go back to the source system. However, there are a few distinct differences you
would do well to be aware of.
The main difference is that a cached copy of a report has a configurable lifespan.
Once the cached copy of a report expires, the next execution of the report will
run in its entirety—sending a query to the source system(s) to return up-to-date
information to the user. This ability to control the lifespan of the cached copy of
a report allows for a ceiling to be set for the maximum latency of the information
contained in the report.
For example, the settings of a report can be configured such that the cached copy
expires after 1 hour. During that 1-hour period after the cached copy is created, all
executions of that report will be satisfied by the cached copy, and no query will be
sent to the data source. After the 1-hour period has elapsed, the next user to execute
the report will have to wait while the report is fully executed against the source
system(s). That execution becomes the new cached copy from which all subsequent
report requests are satisfied for the next hour.
The example scenario from the previous paragraph is not entirely accurate. It does
not take into account parameterized reports and runtime parameter values, which is
another difference between caching and snapshots. If you recall from the previous
section, snapshots can only be created using the default parameter values. On the
other hand, when caching is enabled, a separate cached copy of the report will be
created for every combination of parameter values with which the report is executed.
This may or may not be a desirable behavior. For example, if a report is structured
such that there are many combinations of parameter values and each combination
is typically only executed a few times, then the cached copies will rarely be used to
satisfy a report execution request, which means most report executions will issue a
query against the source system and users will be forced to wait for a full execution
of the report. Furthermore, there is the additional overhead of storing the cached
copies of each version of the report with very little benefit.
 
Search WWH ::




Custom Search