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):
- 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)