Settings to optimize Your DNN installation for speed and efficiency (upto V6.0)

Overview

DotNetNuke is a large and flexible web platform and as such has many configurable settings. Most of these settings have been configured for general ease of use, so it is recommended that we review and modify some of these settings if we wish to improve the overall performance of a DotNetNuke
installation.

1) Host Settings Configuration:
Configuration -> Check For Upgrades:
When this option is enabled, your website will communicate with “DNN Corp” to check for upgrades. An upgrade check will be performed every time you view the module definitions page or if you view a page with the DNN control bar embedded.

We should turn this option off to reduce overhead and remove the annoying nag images.

Appearance ->Show Copyright Credits:
This feature injects the DNN copyrights into the page, this just adds more page weight and is not required.

We should turn this option off to reduce page overhead.

1.2) Request Filter Settings:
DotNetNuke introduced the request filter feature starting with DotNetNuke 4.5.3, this feature enables you to setup request filters to block or redirect users.

If you do not specifically need this feature, then we recommend that you turn this option off.

1.3) Performance Settings
The default DotNetNuke performance settings are ok for testing environments but production environments will require these settings to be modified. The following sub sections will outline recommendations for the configuration of these items.

Page State Persistence:
This setting determines whether the page’s view state is stored in the page or server memory. Although changing this option to “Memory” could reduce the overall size of the request sent to the user, in most cases it causes other problems and I personally recommend NEVER changing this value to anything other
than “Page”.

Module Cache Provider:
The module caching provider setting configures how DotNetNuke will store the output cache of its module objects. The proper configuration of this setting is dependent on the specific environment that the website will be hosted in. Shared Hosting and Dedicated hosting environments will typically see better results using “Memory” caching. In Cloud computing environments, disk based caching makes sense as website content is stored on a SAN or similar device with very good write speeds, and memory availability is limited.

Cache Setting:
This performance setting is used to control how much of the underlying data is cached by DotNetNuke. We recommend setting this option to “Heavy”.

Authenticated Cacheability:
This setting is used to define the cacheability of content for authenticated users, this can be used to optimize what can and cannot be cached by downstream routers and machines when working with authenticated users. For more information on the values in this section please consult MSDN

I recommend that this setting is left at the default value.

Compression Setting:
Enabling gzip compression is an easy way to reduce the size of the site payload and get a nice boost in performance. It is possible to disable the DotNetNuke compression and use IIS native compression, however, we have experienced issues with some third party modules and IIS level compression. Therefore it is recommended that we use the DNN functionality unless there is a specific need to compress at the IIS level.

Use Whitespace Filter:
This setting will strip whitespace from your generated page content following the Regular Expression specified in the Whitespace Filter option under "compression settings". This option is NOT needed if you are using a compression method. If you are not using a compression method and still would like to see a reduction in page size you can use this option which will slim down the HTML size of your pages.

Output Cache Provider (DNN Prof Only):
This provider is used to cache the entire content of a generated page allowing for zero database lookups and page generation activities to be skipped for un-changed content. This option is not available in the community edition of DotNetNuke.

1.4) Other Settings
Enable Users Online:
The Users Online feature allows DotNetNuke to show you which users are currently online. This process adds a fair amount of overhead and it is recommended that you do NOT have users online enabled.

Site Log History:
The Site Log History setting controls the data retention policy used by the DotNetNuke Site Log. We recommend that the Site Log History setting be set to “0” days which will disable all site log functionality.

Scheduler Mode:
This setting controls how DotNetNuke scheduled tasks are triggered. The default configuration of “Request Method” requires that on page requests a check is performed to trigger any tasks. This mode introduces additional request overhead and can delay end-user experiences. We recommend setting this configuration option to “Timer Method”.

Enable Event Log Buffer:
DotNetNuke writes all kinds of log entries to the event log, user login, page changes, etc. Enabling the event log buffer allows DotNetNuke to queue these log items to cache, thus reducing the number of database writes. Therefore it is our recommendation that this setting be enabled on all installations.

Auto Sync File System:
This configuration option enables/disables the automatic file synchronization functionality. We recommend disabling this functionality as it is only needed if files are added to the portal via FTP on a regular basis.

2) Admin Settings:
On DNN 5 portals, un-select “Enable Skin Widgets” if they are not being used. This will prevent additional page resources from being injected, and increasing the size of the page.

3) DotNetNuke Scheduler:
This is another DotNetNuke sub-system that is worth configuring to ensure the website is optimized for performance. The DotNetNuke task scheduler provides vital functionality, however if the tasks are scheduled to run too frequently they will have an adverse impact on the websites performance.

We recommend the following task scheduler optimizations:

• First disable all scheduler tasks that are not required by this website installation.
• Configure “DotNetNuke.Services.Scheduling.PurgeScheduleHistory, DotNetNuke” to run every 12/24 hours (or whatever best fits your portal requirements, based upon how much Schedule Log your website generates)
• Configure “DotNetNuke.Services.Search.SearchEngineScheduler, DotNetNuke” to run every 12/24 hours and retry after 24/48 hours. (again depending upon what best fits your portal requirements). Note: updating this setting will yield a significant improvement in performance.

4) DotNetNuke Event Log
Anyone who uses DotNetNuke for any period of time will soon discover that the “EventLog” can produce a significant hindrance on performance. It is very important to note that DotNetNuke by default does not clear the entries in “EventLog” table. Over time this table will grow to be very large.

You can enable the “EventLog” buffer feature, to minimize the impact, but I recommend truncating this table on a daily basis. This allows for a 24 hour rolling history for any diagnostics purposes and avoids rapid transaction log growth when deleting records. This can be accomplished a number of ways;

• SQL Server Scheduled Job
• Manual process
• Or using a custom module.

Also disable all logs that are not essential for the website installation, this will reduce the number of database requests your website will need to perform, in particular:

• Disable “Application Start” log entries.
• Disable “Application End” log entries.
• Disable “Scheduler Started”, “Scheduler Event Started” log entries.

5) Authentication Providers
Starting with DotNetNuke 4.7.0 additional authentication provider modules were introduced. Website administrators can configure which authentication provider/s is used to authenticate the users against.

Most DotNetNuke sites will only require the standard DotNetNuke Authentication Provider. However, behind the scenes the website will incur a performance hit when additional authentication providers are enabled, even if they are not being utilized.

This performance hit is typically limited to the login page itself where DotNetNuke polls all enabled providers to see if they must be rendered, but the performance impact can be major.

It is our recommendation that all non-essential authentication providers should be disabled.