I present below various Tips & Techniques (not in any particular order) for optimization of a typical DotNetNuke installation.I learned these while using DNN over time, while I encountered some of them while browsing over web.
A typical DNN install requires considerable server resources, and creates significant traffic between the database & web server. These techniques aim to reduce both of these where-ever possible, along with some other optimizations. Some of these may not apply to you, and I advise you to exert discretion in deciding which of these work best for you.
- Host Settings
- Set the “Performance Setting” to “Heavy Caching”.
- Depending upon Hosting resources, set the “Compression Setting” to “Deflate Compression” or “GZip Compression”.
- Depending upon Hosting resources, enable “Whitespace filter” (not of much use, if you have also enabled compression).
- Disable “Users Online” for Installations on which “Users Online” module is NOT used.
- Set the “Scheduler Mode” to “Timer Method”. “Request Mode” causes the Scheduler to be invoked on every request to a page of your installation.
- On sites where Logging is NOT mission critical, enable “Event Log Buffer”, so that log entries are buffered before being flushed.
- On sites where the Site files do NOT update frequently, disable “Auto-sync filesystem”.
- Uncheck “Enable Ajax” on portals that are just informative, and do NOT involve management tasks.
- Admin Settings
- On DNN 5 portals, unselect “Enable Skin Widgets” if they are not being used to prevent redundant skin file downloads.
- Log Settings
Disable all Logs NOT required on an installation. In particular,
- Disable “Application Start”.
- Disable “Application End”.
- You might also want to disable others like “Scheduler Started”, “Scheduler Event Started” etc. depending upon if they are not much useful to you. However, “Sceduler event Failure” should not be disabled to enable debugging of any scheduler issues.
- Schedule Settings
Disable or customize all Schdules NOT required on an installation. In particular,
- Configure “DotNetNuke.Services.Scheduling.PurgeScheduleHistory, DOTNETNUKE” to run every 5 days (or whatever fits best to your portal depending upon how much Schedule Log your portal generates).
- Configure “DotNetNuke.Services.Search.SearchEngineScheduler, DOTNETNUKE” to run every 5 days and retry after 1 day (again depending upon what fits best to your portal. There is no one size fits all approach here).
- Manually optimize all css & js files to remove redundant white-space (or use a free or paid DNN module e.g. Page Blaster to manage this task for you).
- Zero out portal.css (if you dont use it, or better still, delete it).
- Check ~/portals/_default/default.css for any styles not being used on your portal.
- Try to use any other menu except SolPart Menu.
- Try NOT to use table based skins (improves the perceived rendering of your page).
- Cookies: Set the appropriate value for Persistent & Session cookies in web.config.
- Compilation: If you are compiling DotNetNuke or any Extension from source, make sure that you compile the project in Release mode. Moreover, make sure you have debug=”false” in web.config for your production sites.
If you have any other suggestions, or otherwise want to discuss any of the above points, feel free to use the comment form below.
UPDATE (Feb 5, 2015):
I am very excited to announce that we have launched the Caching Provider Module for DNN that can help you greatly improve your DNN site’s performance. Go, check it out here:
The module provides multiple providers for Page and Viewstate caching that combined can greatly improve the page load time of your DNN page as well as reduce the page’s size thus enabling lightning page load times.