Caching is a critical feature for DNN performance and ability to scale. In fact page output caching was one of DNN Professionals signature features when it was released.
Documentation on what caching means as a whole to DNN is currently left to the depths of the code. So let me shed a little light on how caching and more specifically Page Output Caching work in DNN.
Caching is broken up into 3 sections in DNN
- Page Caching
- Core Caching
- Module Caching
1. Page Output Caching
Page output caching is the idea of delivering the entire html payload from cache instead of rendering the page and requesting data from the SQL server or from individual module cache locations.
Because this function happens so early in the http request pipeline it will speed up the performance of your site by a huge degree and something that I think every site needs. Page output caching will also remove viewstate from the page completely reducing the payload.
All of the settings for Page Output Caching are found in page settings under advanced > cache settings.
Knowing generally how page output caching works I think it’s worth discussing what it can’t do in order to better illustrate the situations you may run into.
- Like module caching this feature will not operate when a user is authenticated.
- Only works for GET requests and not POST requests
- Search engines do not get cached pages.
- Pages are cached by TabId and up to 250 variations will be cached based on querystring differences.
- You must explicitly enable page output caching on every page by setting it’s duration.
- In page settings you can set a querystring modifier to either enable or disable page output caching. But this setting only works on a page by page basis with no way of having a host or portal level setting.
2. Core Caching
The core framework of DNN uses memory to store many of the primary subsystems and there is no way to change this storage location. (Not that you would want too)
- Host & Portal Settings
- Page Settings
- Modules on Page
- Module Definitions
- Module Settings
- Files Management
- … and more …
So be aware that the larger your site becomes the more memory it will consume in order to operate.
3. Module Caching
Module caching default settings is found on the Host Settings > Advanced Settings > Performance Settings. These settings include:
- Page State Persistence
- Module Cache Provider
- Page Output Cache Provider
- Cache Setting
- Authenticated Cacheability
Module caching has been part of the framework for a while and is one of the better documented sections. There are a few details that are omitted from that article.
Unless your server is starved for memory I would recommend setting these all too: Page*, Memory, Heavy, ServerNoCache respectively.
An important limitation to understand is that none* of the settings effect authenticated users. So not just admin users but regular registered users as well.
*Page State Persistence is more of a core function but it’s worth detailing how it effects modules. This setting will GREATLY reduce the html sent down the pipe for each page. However by removing the View State from the page and keeping it in memory it will cause issues with AJAX functions where the code uses view state in order to keep track of paging or some other arbitrary variable. It will run for authenticated and anonymous users alike. But if you don’t use modules like that then I would experiment with enabling this feature.