My recent postings regarding DotNetNuke have been very popular among the community and each of them have covered specific aspects of performance improvement. However, none of them have gone through the full collection of "performance optimizations" that are possible. This article is going to summarize the items from the existing articles and will try to explain some additional, bigger picture elements that come into play, and considerations that must be thought of during any site configuration.
First of all, I strongly recommend that you read the two existing postings that I have on DNN performance. The most recent, DNN Performance Tip: Disable Unused Auth Provider which is a simple quick tip for improving site performance on all 4.7.0 and later DotNetNuke sites. Then How I get My DotNetNuke Sites To Run So Fast, which covers my baseline configuration changes to a DotNetNuke system. This article does go into a few additional options as well, each of which will be expanded upon in this article.
What Server Configurations Require Changes
The most common question that I have been asked after posting these articles were, "you mention these are just starting points and that they might need to change, but why?" Well sadly, there is not a good, solid answer to this, as it is really environmentally balanced. But there are a few general recommendations that I have based on the environment used for hosting and changes to my default configuration.
As DNN on cloud hosting providers, such as Mosso, becomes more popular I see more and more people moving to this environment. However, I have noticed that cloud environments do not handle "Module Caching" in Memory nearly as well. For these environments, changing this to "file", seems to provide a 20-30% performance improvement, over baselines that I have evaulated across multiple client sites.
Overall, I have not encountered any other needed changes for these environments.
Shared hosting with providers such as 3Essentials typically do not require any changes to the defaults that I have mentioned before. I have noticed that disk IO, is not as fast as in a Cloud environment so the memory caching method still works well, however, if on a heavily loaded server, you could need to make future changes.
Dedicated and VPS Hosting
When on a VPS or Dedicated server, it is very easy to monitor the memory footprint of the applications. Overall I still highly recommend my default configuration, but if the server needs to host multiple applications, it might be necessary to move the "Module Caching" to disk. This might be needed due to the limited memory, to give some examples, this site, under normal load with Memory for module caching uses about 300 Mb of system ram, and on a VPS with 1gb, that can be cutting it close.
I started hinting about the importance of the skin, and other design elements, in one of the articles, however, I did not go into much detail. The following sub-sections outline my thoughts and experience when it comes to the skin's impact on site performance.
First of all, lets just talk about the skin and how it affects the site. Recently, I have been on a quest to get my DNN sites to validate to XHTML standards as well as moving to semantic markup. SO far the IowaCOmputerGUrus Inc. site has had the biggest improvements, and will validate as conforming XHTML. Since making the changes to the skin to streamline the HTML we noticed overall page sizes being reduced due to the amount of HTML being reduced. In addition, with XHTML conforming code all the way through we have noticed an improvement in loading times, such I assume is due to browser optimizatons.
The key here is that a little bit of work can go a long way in meeting standards and in the process small improvements in performance can also occur. In the skin itself you will typically not see major improvements in loading, but semantic markup, and valid HTML can have many SEO and other benefits.
Skin Objects (Menu's)
This is one of the biggest areas that can be leveraged to help improve the performance of a DNN site, at least in my opinion. When looking at all core SkinObjects, I've noticed that the core DnnMenu skin object is by far the slowest. I have found that great performance improvements have been acheived by swapping the core skin object out for either Snapsis CSSNavMenu or Telerik's RadMenu components. For both this site and the IowaComputerGurus Sites I experience a 50-65% reduction in page load times with the single switch of menu skin objects. To me, it is one of the biggest improvements that I have ever been able to realize.
I'm sure that there are ways to help improve the DnnMenu Skin Object as well, but I am not aware of anything, and for the minimal costs of switching I have never investigated the issue.
Stop Recurring Errors
Another big performance killer for any site is the existance of multiple unhandled exceptions. Every time an exception is thrown there is a bit of overhead for .NET to process it, and then for DotNetNuke to Log it to the EventLog. Reviewing the EventLog on a regular basis to ensure that you do not have any recurring errors is a key to keeping a site running. If you have an error that is happening all the time, it is best to stop them from occuring, regardless of if it is an incorrectly configured module, or a bad piece of code. However, the reality is that not all can be resolved, so don't beat yourself up if you cannot figure one out.
This task although is important, is typically the hardest for someone that is not familiar with .NET debugging and DOtNetNuke. Posting details from recurring errors to forums, such as the one here on my site or DotNetNuke.com is a good way of trying to get help. Otherwise, a consulting firm can assist as well. (See my consulting tab for information on my consulting).
The next most important item, if everything is configured properly is to ensure that the EventLog table is cleaned on a regular basis, since many actions trigger logging, as the table grows in size, the performance of a site reduces. For performance reasons, we truncate our EventLog table every day at 2AM. It helps keep the site and database lean, but still allows us enough time to check for recurring errors. However, other than these items a DNN site should not require much regular attention to keep the performance up after it has been configured.
After dealing with the DNN configuration, the skin markup, skin objects, any recurring errors, and regular cleanup tasks it is time to start looking at third party items and how can they help. Typically this step is not needed for your basic sites. For example, the IowaComputerGurus Inc. site does not use any third-party compression/caching utilities and it performs on par with this site, however, with a much larger amount of content here, I do use a third party tool.
I hope that in this article I have been able to share more of the "how to" information on improving the performance of DotNetNuke sites. Just with all of the other articles on this topic, there is no silver bullet, each implementation must be considered and an appropriate action plan should be identified. Please share any comments below.