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
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
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
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.
This performance setting is used to control how much of the underlying data is cached by DotNetNuke.
We recommend setting this option to “Heavy”.
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.
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 Prol 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
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
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
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.