Report Caching in Reporting Services
A report server can keep a copy of a processed report and return that copy when a user opens the report. This practice is called caching. Caching can shorten the time required to retrieve a report if the report is large or is accessed frequently. If the server is rebooted, all cached instances are reinstated when the ReportServer service comes back online.
Caching is a performance-enhancement technique. The contents of the cache are volatile and can change as reports are added, replaced, or removed. If you require a more predictable caching strategy, you should create a snapshot. For more information, see Creating Snapshots for Report Execution.
A cached instance of a report is based on the intermediate format of a report. The report server generally caches one instance of a report based on the report name. However, if a report can contain different data based on query parameters, multiple versions of the report may be cached at any given time. For example, suppose you have a parameterized report that takes a region code as a parameter value. If four different users specify four unique region codes, four cached copies will be created.
The first user who runs the report with a unique region code creates a cached report that contains data for that region. Subsequent users who request a report using the same region code get the cached copy.
Not all reports can be cached. If a report prompts users for credentials or uses Windows Authentication, it cannot be cached.
Preloading the Cache
You can use the data-driven subscription feature to populate the cache with a collection of parameterized report instances. Populating the cache is achieved through a specialized rendering extension, named the Null Delivery Provider, that is available when you define a data-driven subscription. When you specify the Null Delivery Provider, the report server targets the report server database as the delivery destination.
This feature is especially useful if you want to cache multiple instances of a parameterized report, where different parameter values are used to produce different report instances. Note that you can only specify query-based parameters on the report. In contrast with other delivery extensions, the Null Delivery Provider does not have delivery settings that you can set or drive through a subscription definition.
When you define the subscription, you can schedule how often the reports are delivered to cache. Note that the Execution properties of the report must include cache expiration settings in order for new copies to be delivered. This setting must be consistent with the schedule you define. For example, if you define a subscription that runs every night, the cache should also expire every night prior to the subscription run time. If the Execution properties do not include expiration times, newer deliveries will be ignored.
For more information about using data-driven subscriptions, see Data-Driven Subscriptions.
Refreshing the Cache
The report server caches reports based on report execution options. Execution options determine whether a report is cached and the length of time it stays in cache. After some number of minutes or at a scheduled time, the cache is emptied. The cache stays empty until a new report execution operation occurs and a new copy of the report is cached. For more information, see Setting Report Execution Properties.
To a user, report execution options are invisible. There is no indication that a report originates from the cache or is a freshly processed report. The only evidence available to a user of how a report is executed is the date and time that the report ran. If the date or time is not current and the report is not a snapshot, the report was retrieved from cache.
You cannot delete the cache directly unless you use the SOAP API. If you use Report Manager to set caching options, you can set a schedule or specify a time period after which the cache expires. When a cached report expires it is removed from cache so that a newer version can be stored.
Scheduling Cache Expiration
You can schedule cache expiration on a recurring date and time. If a cached copy of a report exists when the scheduled time occurs, it is removed. You can use a shared schedule or report-specific schedule that applies only to cache expiration. If you use a shared schedule and it is subsequently paused, the cache does not expire while the schedule is inoperative. If the shared schedule is subsequently deleted, a copy of the schedule settings is saved as a report-specific schedule.
If a schedule expires or if the scheduling engine is unavailable at a cache expiration date, the report server runs a live report until scheduled operations can be resumed (by either extending the schedule or starting the scheduling service).
Other Conditions that Cause Cache Expiration
A cached report can also be invalidated in response to the following events: the report definition is modified, report parameters are modified, data source credentials change, or report execution options change. If you delete a report that is stored in cache, the cached version is also deleted.
If a report cannot be rendered from a cached instance for any reason (for example, if the parameter values that a user specifies are different from those used to produce the cached report), the report server reruns the report.