Blogs

DNN Performance: Understanding ModuleCache and PageOutputCache

26 May

Over the past 4-5 months my company IowaComputerGurus has help to optimize the performance of more than 50 different DNN based websites.  This is a major uptick in performance related inquiries as compare to past years which is to be expected as website owners become more-and-more concerned about the performance of their applications. In the current era it is important for websites to be fast not only for the user experience, but also for placement within the Search Engines.  The faster the internet connections we get the more impatient our users are when it comes to waiting for our sites to load.  Depending on who you talk to you will see metrics that show page load times of anything greater than 3 seconds can lead to lost customers & revenue for your website.  What exact e"metric you are looking to meet is up to you, but regardless a DNN based site can still easily render in sub-second times with proper configuration & maintenance.  In this post we will look into two of the most commonly overlooked configuration elements for performance the ModuleCache and PageOutputCache.

Cache Modes

The first thing to discuss as part of this is the "mode" of caching.  These are configured under "Host" -> "Host Settings" -> "Advanced Settings" -> Performance.  For both Module Caching & Page OUtput Cache (If supported, see below) you will have options for where to store the cache.  The default options are "File" and "Memory".  Which you select will depend on the exact environment that you are hosting in.

My standard recommendation for ALL users is to use the Memory option.  Memory is the fastest option in most application as it avoids any delays in writing to a physical disk, and also has a much faster process for expiration of cache.  However, in certain environments where memory is at a premium, such as shared hosting, if you find that DNN is consuming more memory than allowed, you can change this to file.  Just remember that the site WILL be slightly slower.

Module Cache?  I Didn't Think I Could Do Anything!

Within DNN one of the two different cache sub-systems, and the only one available in DNN Platform is Module Cache.  The module cache is DNN's internal ability to cache a copy of the content to be rendered to the user, this allows the site to load more quickly by obtaining content from the cache rather than by asking the module to render the content.  Typically users think they have no need, or ability to configure this type of caching as many modules have values already set and people are scared to change them.  However, one of the biggest things you can do as a site owner is to configure these values to help further optimize the items that are loaded.

Module Cache time is set on a per module instance basis and is access via the "Settings".  The HTML module for example has a default cache time of 1200 seconds, or 20 minutes.  This works pretty well, but how often are we really changing HTML content every 20 minutes?  On most sites this isn't the situation, so why not but this value up to 2400, 3600, or even higher values.  Yes, more items will be stored in the cache, but the site performance will be better.  

NOTE: This option is great, but be cautious if you are using a module that currently has a cache time value of 0.  Modules that accept user input and similar CANNOT be cached in this manner.  If in doubt, contact the module developer to confirm its compatibility with module cache.

Page Output Cache

Page output cache is one of the often overlooked benefits of Evoq Content by those with a license to the product.  Users on DNN Platform at this time do not have an option to enable this functionality, however, various third parties have hinted at the development of a feature for this in the future as an add on.  Regardless, this type of cache is very similar to that of the module cache, but it applies to the entire page, this includes all modules, menus, and other content.  

Page Output Caching is enabled on a page-by-page basis and all modules on a page must be tested to make sure that this will work.  However, once enabled pages that have this option enabled will be rendered WITHOUT a single database transaction as long as the content was able to be located in the cache.  This results in substantial performance improvements for users.  

NOTE: You must enable this on a page-by-page basis.  I strongly recommend checking each page's functionality after enabling to check for any oddities.

Final Notes & Behaviors

Understanding and using these two types of caching can be imperative to having a proper functioning DNN site.  It is equally important to understand that these types of cache only work in certain circumstances, and once users are logged in, most of these cache operations are no longer useful.  As such, if you site is 100% authenticated users it is important to look at other vectors of improvement as your gains with caching will be minimal.  I hope that this information helps you in your performance tuning needs!

tags: DNN, DNN Administration, Performance
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Connect with Mitchel

I hope the information here has been helpful. To stay connected you can also subscribe to blog updates via email, contact Mitchel about consulting services, or reach out for assistance via CodeMendor

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.