April 11, 2014

Avoiding Performance Issues with Multi-Portal DNN

In the first 3 months of 2014 I have encountered multiple multi-portal DNN installations that have been suffering from severe performance issues.  In most cases these users had already followed the whitepaper recommendations that I have had published since early 2007 and the sites were still slowing to a crawl at best.  Digging in, each time I found that a single fundamental issue was the root cause, with a few other secondary considerations.  Given the popularity of DNN continuing to grow and the relative ease of Multi-portal configurations I though it would be important to share.

Background

Just to make sure that everyone is on the same page with regards to what a multi-portal installation of DNN is.  I'm specifically referring to any installation of DotNetNuke that has more than one individual URL associated to it.  For example MySite.com and MyOtherSite.com that serve different content.  You would have initially configured a multi-portal installation via "Host" -> "Site Management" on current editions of DNN.

Improper IIS Setup is Key Performance Issue

The number one issue that I see with individuals setting up multi-portal DNN installations is that they setup a separate Site within IIS on the server.  Making two different sites that point to the same physical files, the same database.  This is the number one thing TO NOT DO with DotNetNuke.  

In this situation things such as scheduled jobs that should be running once every _ minutes or similar have no recollection that another copy of the same application exists.  Therefore, this results in the scheduled jobs running twice during the times when it should only being doing things once.  This can have varying levels of impact to performance and stability of the application.  One example of a major performance hit would be indexing content for the site search function.  In this situation both application pools will try to index content, both using high amounts of CPU on the webservers as well as impacting the performance of the database server in a negative manner.

DNN does have support for Web-Farm environments and the execution of jobs on a single server.  HOWEVER, that is by server name only, not by application pool or other identity.  

A proper setup of IIS involves ensuring that bindings as needed for the additional domains are simply added to the main DotNetNuke Website   By keeping with 1 application you can keep the site running well.

Consider Traffic & Loads of Sites & Business Need 

The second area that I have encountered a number of concerns with recently is improper consideration of traffic, server load, and business needs of each site.  The key here is remember in a multi-portal setup of DNN.  ALL sites are tied together, if one site goes down, the rest of the sites go down.  If one site gets a lot of traffic an impacts performance of the server the other sites can be impacted.  

Conclusion

I hope that this information has helped you understand a bit more about the do's and do not's of DNN Multi-Portal configuration.  DNN is a great platform and can work well with multi-portal setup but proper consideration is key!

tags: DNN, DNN Administration, Quick Tips, Performance
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.