New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Performance best practices

Return to previous page

  • 4/7/2015



Performance best practices

Last updated long time ago



(Enter the content of this article below)


Note: this wiki also contains other pages on Best practices

This page will cover a number of performance best practice, includes the webserver (IIS), database server (SQL) and DotNetNuke itself.

DotNetNuke performance

  • There are a number of setting changes you might want to consider when tweaking DotNetNuke Performance
  • If you need to scale beyond one webserver, please read about Caching Providers
  • Optìmizing your scheduled tasks
  • Authentication Providers - By default DotNetNuke ships with 3 types of authentication provider
    Only “DNN” is mandatory. If you have not deployed DotNetNuke yet consider removing the openid and cardspace providers from install/AuthSystem
    If you've already installed DotNetNuke you must check if they’re Enabled before deleting
    If enabled – run SQL to ensure you don’t orphan users

SELECT COUNT(*),AuthenticationType from UserAuthentication  group by AuthenticationType

  • Ensure debug=false and trace=false is set in your web.config (or better retail=“true” in machine.config)
  • Ensure any antivirus has exemptions for the website folders – ideally all, if not , all but “/portals”. Note: the AVG Antivirus online shield has been massive to cause massive slow downs. Presumably this is an error with that product and will be resolved, but if you are seeing slow downs consider disabling it.
  • If your site does not use any DotNetNuke Widgets you can disable these under Admin->Site settings. More details on this can be read here
  • jQuery may be loaded from a content delivery network to improve download speed and reduce the number of requests for it (if a previous site has referenced the same CDN then the file will not be downloaded again. Please see jQuery host settings for more details


Do not:
  • Don't use Webgardens - does not syncronize cache across threads automatically.

  • Consider using IIS compression. Static compression will take care of images and other documents, while dynamic compression will handle ASP.Net content. Whilst DotNetNuke has support for compression (dynamic only), offloading this to IIS is recommended as it is likely to perform marginally better and offers some additional options. To see how to set it up please read this . Note: if you enable IIS dynamic compression be sure to disable DotNetNuke compression (host->host settings screen)

SQL Server

  • If you need your site to scale (i.e. run heavily used web sites) do not use SQL Express. SQL Express has a number of limitations, including being limited to only 1 CPU and a maximum of 1GB of memory for the buffer pool. More information on the limitations here, more information on different editions here
  • Do not run Internet Information Server (IIS) on the same physical machine as your database server. Both IIS and SQL attempt to reserve memory for future operations and they are better being on seperate servers to stop unnecessary memory allocation/deallocation and paging operations.
  • Use the most recent version of SQL Server and its service packs that you can - Microsoft is continually improving core speeds and tweaking the optimization engine, so as rule of thumb the more recent versions of SQL will handle load better.
  • Identify any large tables so you can determine if you need to take action - a script such as this will allow you to see table sizes across a database. Alternatively, the following is unsupported by Microsoft but works across all current versions

sp_msforeachtable "sp_spaceused '?'".

  • Whilst not a SQL Server optimisation directly, many sites find that they can reduce SQL load by controlling the size of the EventLog and SiteLog tables (note: in general the recommendation is to consider offloading site logging to a provider such as google analytics). Note: Both these tables can contain important information and should be backed up before clearing them down. To clear them down, rather than using a DELETE query (which is a logged operation and can itself time out), it is recommended that you use TRUNCATE (a single logged operation) e.g.



Note: if your site uses objectqualifier or databaseowner values then you will need to replace them with the relevant values

TRUNCATE TABLE {databaseOwner}{objectQualifier}Eventlog

TRUNCATE TABLE {databaseOwner}{objectQualifier}SiteLog

This query can be ran manually, or created as a sql job or can utilise a utility such as Scheduled sql jobs to run it on a regular basis.

Note: 5.6.0 improved DotNetNuke's contained improvements to ensure that DotNetNuke does a better job of removing old entries in the Eventlog.

  • Create a SQL Server maintenance plan - maintenance plans can be used to back up your data (which also clears down the transaction log, saving space), update index statistics (which can improve query speed) and compress and reorganize data and index pages (which improves the speed that updates occur). Microsoft provide a simple wizard to help set these up. If you do not have access to your SQL Server to create them please contact your hosting provider to ensure they've created them on your behalf.
  • This blog post by Sebastian Leupold has some database performance tips.


  • Uninstall any unused modules. This will remove unnecessary assemblies from the /bin and improve startup performance as well as making more memory available for caching. If your site is running 5.0 or higher, go to Host->Module definitions - if the "In use" column says "No" (rather than "Yes") consider deleting the module. If the "In use" column says "Yes" but you are surprised by your usage, the "Yes" text is a hyperlink that will allow you to determine where instances are installed. Alternatively the dashboard module can be used to see this data.
  • empty the recycle bin - log in as a host and go to admin->recycle bin and delete any pages/modules.
  • disable users online - under Host->host settings, advanced settings, ensure "enable users online" is unchecked if you are not using the users online module. Note: this module is quite "chatty" as it needs to periodically update user counts, so if you don't absolutely require this functionality, it is better to uninstall it.
  • Log buffering - by default DotNetNuke logs each event as it happens. However you can buffer these database writes so it only happens in batches (note: if the site recycles you may lose some data). To use the function, under host->host settings locate"Enable Event Log Buffer? " and set it to a value higher than 1.
  • Comment out any unused module or page caching providers in web.config. Whenever a module or page is updated every caching provider is told to remove an item from the cache, even if the provider may not currently be in use.
  • Use memory based caching whenever possible. If you are not using a shared hosting provider, you should use memory based caching if possible.
  • Enable compression in the performance settings, unless of course you have compression turned on at the web server level.
  • Search engines - Search engines can add a load onto your site whilst spidering content. You should take steps to control or eliminate this e.g. in the robots.txt file consider removing certain spidering agents


User-agent: MS Search 4.0 Robot Disallow: /
User-agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 4.0 Robot) Microsoft Disallow: /

In addition, you can exert control over some engines via robots.txt
Crawl-delay: 10

Request-rate: 1/5 # maximum rate is one page every 5 seconds
Visit-time: 0600-0845 # only visit between 06:00 and 08:45 UTC (GMT)

Note: is a good resource

  • For sites that do not have content that requires security, consider changing the Authenticated Cacheability value
  • DotNetNuke supports file system auto synchronisation. This is intended to pick up files uploaded outside of the system e.g. FTP'ed files. If you site does not use this then consider switching the Auto-Sync File System to OFF in host settings.


Many of the recommendations in the Skinning best practices will reduce page size, lowering page load times and increasing performance

Additional references

No sections defined
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out