Emedia,
I know this is an old post - however for searches related to DNN Output Caching this is one of the top results. This indicates to me that there is little to know information out there related to Output Caching on DotNetNuke. The response provided to your question, in my opinion, is woefully inadequate. You clearly asked HOW to set up providers, and seeked explanation on what (if any) the benefits of Output Caching would be.
I've recently been tasked with DNN development, and am honestly shocked at the lack of information and degree of ambiguity that currently exists regarding Output Caching in DNN.
That being said - I can answer your question (for internet posterity) - and will actually be asking some additional questions at the end of my reply. All statements apply to DNN 5.6.3.
1. The Output Caching Providers available to the system are defined in the web.config file for the site. There is a section that should be set up as such:
<outputCaching defaultProvider="[PROVIDER NAME HERE]">
<providers>
<add name="[PROVIDER NAME HERE]" type="[FULLY QUALIFIED PROVIDER NAMESPACE.CLASSNAME]" providerPath="\Providers\CachingProviders\[SOME PROJECT DIRECTORY FOR THE PROVIDER]" />
</providers>
</outputCaching>
2. In respect to the performance gains... Output Caching, in my opinion, is probably one of the most performance enhancing mechanisms you can apply to a web application. If implemented *CORRECTLY* (which i'm not sure DNN does) the ASP.NET application request life cycle should be short-circuited at the ResolveRequestCache event (stage 8 of 26, see
http://msdn.microsoft.com/en-us/libra...) bypassing 95% of the server processing involved in handling a page request.
The idea is that the HTML output for a page, which is ultimately generated and delivered to a web client, is tied to a key (typically some combination of URL and QUERY PARAMETERS) and cached for re-use later. At step 8 in the lifecycle, ASP.NET checks for the existence of previously cached HTML for the request. If it exists, it returns what was cached and aborts. If it doesn't exist (or is expired), it proceeded as it normally would, and caches the result of its labor (for subsequent requests) at step 20.
In short, all the work involved in generating that HTML (IIS worker process cycles, Database Calls, etc) is bypassed and content is delivered REALLY FAST.
CAVEATS:
1. Properly implemented Output Caching should only serve cache to GET requests (not POST). Any page handling a POST verb is likely doing some processing related to the POST data, and short-circuiting the .NET life-cycle would kill that. You should load all dynamic pages that you wish to be cached via "GET" as opposed to "POST" and just pass any variables required to uniquely identify the content in the "GET" query string. e.g. "/user/profile/myprofile?id=200" can be cached if it is requested as GET as GET does not imply you are doing any work against that page - just requesting its current state. if you are loading a page with a module that POSTs back to itself that is fine - you can serve the initial GET request from cache - and bypass caching any subsequent POSTs.
2. Ideally implemented Output Caching should be smart enough to invalidate/delete certain keys based on updates made to the site. e.g. if you update the content of a DNN HTML module, the cache for that entire page should be invalidated right away - so that your users will see changes right away as opposed to having to wait for the Output Cache to expire. This is an ideal requirement because some business rules will easily work under a system where changes don't become visible right away, despite that not being ideal.
In a shopping cart for example, the url /viewcart.aspx?cartid=GUID might be cached. If someone adds something to their cart, the site should invalidate output cache for that page/key so that the cart is updated right away.
3. (if you aren't using a web-farm, skip this). Ideally implemented Output Caching should be smart enough to invalidate keys across a web farm. Syncing cache across a web farm, in my opinion, is not a huge deal from a delivery standpoint. If one server has a slightly updated cache than another for a small period of time - who cares. Half your users might see a slightly older version of a page. However, if you explicitly delete something from the cache - ideally that should be propagated across a web farm.
All of that being said - I've been attempting to implement my own output caching provider for DNN 5.6.3.
1. I've created a class which inherits from DotNetNuke.Services.OutputCache.OutputCachingProvider
2. Absolutely NO documentation exists that explains what the abstract methods should do, however I think I've implemented them correctly to serve outputcache via the ASP.Net Cache[] object.
3. I've registered the provider in the web.config as outlined above, and I can see the site is invoking the "GetItemCount()" and "Remove()" methods - so I know it is properly registered as a provider.
MILLION DOLLAR QUESTION: What settings must be set in order for me to see the site actually attempt to fetch/set cached content via the GetOutput() and SetOutput() methods. DNN is taking all the steps necessary to invalidate cache, but it seems to NEVER be trying to save to or serve from the cache.
Please advise.
Thanks