Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Separate database for each portal?Separate database for each portal?
Previous
 
Next
New Post
4/29/2008 2:37 PM
 

If you point more than one worker process at a single DNN install then you will also be running multiple instances of the scheduler and multiple application caches.

The multiple application caches holding the same "global" objects is why it takes a lot more memory.

Running redundant scheduler tasks at the same time is also bad for performance if it doesn't lock up completely.


DotNetNuke Modules from Snapsis.com
 
New Post
4/30/2008 5:46 AM
 

John Mitchell wrote

If you point more than one worker process at a single DNN install then you will also be running multiple instances of the scheduler and multiple application caches.

The multiple application caches holding the same "global" objects is why it takes a lot more memory.

Running redundant scheduler tasks at the same time is also bad for performance if it doesn't lock up completely.

Are you referring to WS2003 Task Scheduler or some other scheduler within DNN? - sorry for the confusion, I am still learning about DNN internals.

With regard to memory overhead, doesn't it amount to much the same amount of memory whether you implement two sites (say) using a single DNN installation with 2 portals each running in a different application pool (2 processes) or two separate DNN installations, one for each site (2 processes)?

Taking on board your ealier point about the reasons for not using separate portals within a single DNN installation to implement separate sites, I did not follow what you meant when you said:

  • They will not be sand-boxed at the physical file system so access to the file system through FTP can not be granted.
  • And the points made by Darrin McQuay and Chris Hammond regarding the need for a separate IP address for each site / portal if using SSL would presumably also apply to the case of two separate DNN installations, if each were running one of the two sites each with its own domain name?

    Nevertheless, I find your earlier points regarding the general wisdom of using a separate installation for each site convincing and probably good advice, which I intend to follow.

    My worries about disk-space are unfounded, I think, since I just looked at the size of my DNN installation on my VPS and, from the 4.8.2 install (without source) and with no extra modules installed and a single portal with no extra pages or skins it comes to about 23MB, so even after adding pages, modules, skins etc, I could probably fit a couple of hundred of these on my VPS.

    Clearly, memory and availability of IP addresses are going to be much more significant limiting factors. My current provider only allows one IP address per VPS, so it looks like I'm going to be looking for another provider soon - any suggestions welcome.

     
    New Post
    4/30/2008 8:15 AM
     

    Steve Taylor wrote

    Are you referring to WS2003 Task Scheduler or some other scheduler within DNN? - sorry for the confusion, I am still learning about DNN internals.

    The DNN scheduler.

    Steve Taylor wrote

    With regard to memory overhead, doesn't it amount to much the same amount of memory whether you implement two sites (say) using a single DNN installation with 2 portals each running in a different application pool (2 processes) or two separate DNN installations, one for each site (2 processes)?

    Yep, just about.

    Steve Taylor wrote

    Taking on board your ealier point about the reasons for not using separate portals within a single DNN installation to implement separate sites, I did not follow what you meant when you said:

     They will not be sand-boxed at the physical file system so access to the file system through FTP can not be granted.

  •  

  • Since they share the same physical file locations, granting FTP access to the install would allow any one to alter everyon'es setup.  You can grant FTP access to just the portal levels but, in reality, managing a DNN site/portal doesn't need FTP except for upgrading.

    Steve Taylor wrote

    And the points made by Darrin McQuay and Chris Hammond regarding the need for a separate IP address for each site / portal if using SSL would presumably also apply to the case of two separate DNN installations, if each were running one of the two sites each with its own domain name?

    The separate IP for SSL is an IIS requirement, not DNN.  Though a wildcard SSL would work, it wouldn't be as easily trusted.

    Steve Taylor wrote

    My worries about disk-space are unfounded, I think, since I just looked at the size of my DNN installation on my VPS and, from the 4.8.2 install (without source) and with no extra modules installed and a single portal with no extra pages or skins it comes to about 23MB, so even after adding pages, modules, skins etc, I could probably fit a couple of hundred of these on my VPS.

    Clearly, memory and availability of IP addresses are going to be much more significant limiting factors. My current provider only allows one IP address per VPS, so it looks like I'm going to be looking for another provider soon - any suggestions welcome.

     

    Physical RAM is king, and unfortunately usually costs a premium in a virtual server.  SQL space can be important as well.

    But you're definitely on the right track.

    Jeff

     
    New Post
    4/30/2008 8:38 AM
     

    Yes, I was referring to the DNN Scheduler which runs on a background thread.  It's application space will start it's own background thread.

    Yes, two sites that are completely seperate would be roughly the same as having two application processes pointing at the same DNN install. 
    My comment was in relation to one DNN install and someone saying that it took a lot of memory. 
    Some people might expect that if you point two applications at the same install that there would be sharing involved and use less memory, but it really doesn't reduce the memory at all.

    You are also right on in your finding that memory and IP addresses will be your limiting factors. 
    Although the IP address problem may be solved with one of the new UNC/UCC SSL certificates.

    http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/118/threadid/182168/scope/posts/Default.aspx


    DotNetNuke Modules from Snapsis.com
     
    New Post
    5/2/2008 5:58 AM
     

    Interesting new certificates - I was not aware of them but will certainly bear them in mind.

    Thanks to all who contributed to this thread - I found it interesting and informative. I has also changed my way of thinking about the appropriate use of portals in DNN.

    Take care,

    Steve Taylor

     
    Previous
     
    Next
    HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Separate database for each portal?Separate database for each portal?


    These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

    For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

    1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
    2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
    3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
    4. No Flaming or Trolling.
    5. No Profanity, Racism, or Prejudice.
    6. Site Moderators have the final word on approving / removing a thread or post or comment.
    7. English language posting only, please.
    What is Liquid Content?
    Find Out
    What is Liquid Content?
    Find Out
    What is Liquid Content?
    Find Out