This is a training session for performance issues on DNN. It takes about 2 hours. It uses the 2illumin8 training model. 

Training Specs

Goals of this Training

Ensure that all participants have a broad overview of all the performance topics relevant to DNN. This include the whole spectrum from slow devices, networks, older browsers, bad images/css as well as server, code an DB issues. 

It also contains references to tools and logs where you can see in-depth what is taking how long. 

Intended Audience

This training is targeted at people who have already had some experience with DNN at a technical level - for example Web Designers, Developers and IT-Operations. It's not suited for content-editors, as it's technical.

Also see Useful Tools

DNN specific

See DotNetNuke Wiki - Performance best practices

• SiteLog is very large
  • SiteLog should be limited to 0 (disabled)
  • DNN Scheduler 'PurgeSiteLog' should run once per day
• EventLog is very large
  • should be limited to 400 records
  • DNN Scheduler 'PurgeLogBuffer' should run every 5 minutes
  • Event Log Buffer should be enabled (to prevent every item written to DB immediately)
• Schedule History is very large
  • DNN Scheduler 'PurgeScheduleHistory' should run
  • Ensure a record limit is set for each active schedule
• Files Table is very large
  • Disable 'Auto-Sync File System'
  • Disable SynchronizeFileSystem Scheduler
• Search Engine Scheduler: Disable if search is not needed or reduce the scheduler frequency.
• Configure Log4Net to clear old Logfiles automatically
  • Files are saved to /Portals/_default/Logs and this folder can grow very much.
  • Configure DotNetNuke.log4net.config to keep only most recent errors.
• Disable Skin Widgets.

Usually no more relevant to DNN 7 and newer

• Many Tabs/Pages
  • > workaround migth be to enable Heavy Caching (Host-Setting)
  • Clear the DNN recycle bin!
  • (Remember that DNN has a tab-order. On every page-move/page creation this gets updated but is inefficient. -> fixed in DNN 7)
• DDR Menu is slow with about 1000 - 4000 Pages
• Tabs Table is very large/ DNN Recycle Bin contains many items
• DotNetNuke cache settings are unoptimized
  • > Heavy Caching must be enabled to cache the Tab Structure
• \Portals\0\Cache contains more than 1000 .resources files
  • Disable Module Caching of modules like Text/HTML. A web server is usually much faster to load HTML from the DB than from a folder with thousands files.
    > enable Memory Caching instead of file based caching!
• Delisoft_TabLocalization_ViewState Table is very large
  • enable the Delisoft ViewState purge scheduler
• Log files are created at \Portals\_default\Logs\ (EventLog, ExceptionLog, etc.)
  • > Disable old XML logging method
• Maybe some DNN Bugs
  • DNN 7.2.2 Caching Issue - Change urlformat="humanfirendly"
  • DNN 7 Advanced URL Management (AUM). Uses almost 35% of CPU per Request (DNN-Sharp, 16.12.2014)
  • FiftyOne Mobile Redirection. uses almost 8% (?) of CPU per Request, probably never used (DNN-Sharp, 16.12.2014)
• Disable DNN Copyright - minor impact

ASP.Net and IIS

• Thumbnails are generated at runtime which causes a high CPU usage in IIS process
  • Enable Thumbnail Caching/Output caching.
• A http Module is installed, e.g. PHD SpamStopper which causes a high CPU usage in IIS process. Disable this module. Especially SpamStopper causes a very high IIS usage.
• ASP.Net ViewState is very large
  • Finde out where it comes from with ASP.Net Trace (www.mySite.com/Trace.axd)
  • Try to keep View State on the server (e.g. in DNN is a feature "Page State Persistence", but use it very carefully because it could cause session overlaps)
• First application startup takes very long.
  • IIS loads every .dll file in /bin folder into it's memory. Try to keep the amount of dll files as small as possible. Especially in DotNetNuke uninstall unused modules.
• When using a Network-Share (\\server\share):
  • Configure the file server
  • Configure the IIS Server to use this
• Optionally: Configure Cache-Control HTTP-Header for images to be different. DNN has a default of 1 year of caching (cacheControlMaxAge), but 30 days would be better in most cases.

SQL Server specific

• SQL process causes a high CPU usage
  • Aanalyze it with Performance Dashboard Reports
• Auto Shrink doesn't run
  • Auto Shrink could be enabled on every Database
• SQL Transaction log is very large
  • Recovery Model should be "simple" on every Database if no SQL-Backups are made
• Indexes are missing
  • Check them with "Missing Index Report" in Performance Dashboard Report
• Indexes are unorganized and might have a large amount of unused space
  • Rebuild or reorganize the indexes ...
• SQL Server Instance - Memory limit should be set, otherwise SQL Server uses as much Memory as it can get (bad for other processes on the same server)

General stuff

• HTTP compression should be enabled in IIS
• Antivirus software on server can degenerate and cause high CPU usage. If possible database files should be excluded from Antivirus software.
• SQL Server Express Edition Instance runs at 1 GB memory (Momory Limit). This can cause IIS to run on high CPU and slow down Website performance.
• A Proxy is enabled (e.g. IIS Application Request Routing ARR)
• An Application Firewall is enabled that analyzes each HTTP Package (actual Payload/Body, independent of HTTP Headers)