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 thought 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 with 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 set up 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 be doing things once. This can have varying levels of impact on the 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 identities.
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 to 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 the performance of an impact 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 the multi-portal setup but proper consideration is key!