My recent postings regarding DotNetNuke have been very popular among the community and each of them has 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.
Existing Articles
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.
Cloud Hosting
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 evaluated across multiple client sites.
Overall, I have not encountered any other needed changes in these environments.
Shared Hosting
Shared hosting with providers such as 3Essentials typically does 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.
Skins
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.
Skin Impact
First of all, let's 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 optimizations.
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 achieved 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 existence 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 key to keeping a site running. If you have an error that is happening all the time, it is best to stop them from occurring, 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).
Routine Cleanup
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 the logging, as the table grows in size, the performance of a site reduces. For performance reasons, we truncate our EventLog table every day at 2 AM. 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.
Third-Party Compression/Caching
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.
The goal of implementing a third-party compression/caching tool is very simple, to provide better caching and compression functionality to improve the performance of the site, and reduce the load on the server. The Gold standard if you will of this has to be Snapsis Page Blaster in my opinion. Not only does it provide a great caching system, but it also provides CSS and JavaScript merging abilities, allowing the total number of HTTP requests to be reduced. Just like the other solutions though, you must find the right balance with tools such as PageBlaster and must balance the configuration for your environment.
Conclusion
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.