Report Caches Overview and Best Practices

MicroStrategy report caches store all report results in I-server for fast retrieval. They reduce the response time to bare minimum as compared to the reports that execute against cubes, aggregate tables, or fact tables on the data warehouse.

How does Report caching work?
A user runs the report for the first time against the data warehouse database. I-Server caches the result set and also returns them to the user. Now, if any other user runs the same report, the I-server uses a matching algorithm to check if it can re-use an existing cache. If the matching algorithm shows that the cache is not valid, I-server will query the data warehouse for the report. However, if the cache is determined to be valid, I-server will retrieve the result from the cache, thereby saving time and resources.

Report Caches Best practices

• Although given the advantages of caching technology, it is not feasible to cache all the reports that exist in the system, due to degree of personalization and security for the reports, limited amount of RAM, and the available batch window time. So it is important to prioritize and choose which reports are good candidates to be cached. Frequency of use, especially for shared reports is a good prioritization criteria. 
• Caching all reports at the project level is only practical for small projects involving limited personal object creation
• Not all shared reports and documents are good caching candidates if the diversity of content to be viewed by users is high. For example, a prompted report that is heavily personalized by each user will not be a good candidate for caching, but a prompted report where 90% of job executions use the same prompt answers could be a good candidate for caching, as Caching for prompted reports is tied to specific prompt answers. For a highly prompted report to be effectively cached, every possible combination of prompt answers would need to be pre-cached, making this highly impractical if not impossible proposition given RAM and batch window limitations.
• Caching should be disabled at the report object template level for report wizard, report builder, and blank report templates. These templates are used to create and save personal reports.
• It is recommended to use the Maximum number of caches setting in Project configuration Editor to limit the number of caches creation allowed per project.
• You can use Microstrategy Enterprise manager to analyze system usage data and identify the reports that fall within the frequently shared reports category and will therefore be good caching candidates.
• Avoiding per user cache generation- When caches are created for each user, by definition they cannot be shared with other users of the project. Caching per user basis means that most of the caching resources would be spent creating and maintaining redundant sets of memory structures with very little potential for reuse. 
• Enable XML caching for reports - Report caches are stored in binary structures in file and in memory. Given that the Web server requires an XML representation of the report to generate the necessary HTML code to ultimately render it on the client, a “Binary to XML” conversion step is required as part of processing a cached report. When XML caching is enabled, this extra conversion step can be completely skipped, making the rendering of a cached report even faster. When cached, the XML representation of the cached report takes up space both on disk and in memory. As a result, turning XML caching on has an impact in terms of increasing RAM usage on Intelligence Server.
• Allocating Enough Memory for Report Caches is very important. If not handled well, it will significantly degrade Microstrategy performance. For understanding the underlying issues due to this and to learn more about how to focus on memory capacity planning for report caches of your Microstrategy server, refer post. 
• Practicing good cache maintenance strategies such as deleting obsolete caches in a timely manner is very helpful too; refer post.