Please excuse just a little extra ongoing confusion - although thank you very much for the information as this is certainly helping me (and I hope others) understand it a lot better.

On my VPS account I have one DNN 440 instance. That instance currently has 9 portals on it, each of which is a different website with its own unique domain name. Each domain is a unique website and all websites run (as portals) within the same DNN instance. I don't have multiple domains pointing to the same 'website'.

Do I uderstand it correctly that it is not really the DNN instance, but rather the domain name, that IIS assigns these app-pool resources to? If I tell my host to put all domains that point to the same DNN instance (even though they are different 'websites') in one app pool, then I will possibly save masses of memory on the dll's.

On that note, wouldn't one therefore always want all domains that point to any portals within the same DNN instance to be placed in the same app pool?

I'm really digging for this information because in future I might have 200 different domains/websites running off this single DNN instance and I need to figure out how to stop it using 200x50mb of ram when they all fire up. I think you're saying that I could configure them to use just 1x50mb plus caching etc?

You see... I wouldn't run a keepalive on 200 low-use single page websites if they needed 50mb each, but I would run a keepalive on a single one if it kept the dll's loaded for all 200.

I think this is the question: Does each domain that points to a unique website require a seperate IIS app-pool, or can many domains that point to many sites within the same DNN instance share the same app-pool? If the latter is correct, then I will tell the host to assign all the domains to the same app-pool. Why would one ever have them in separate pools?

I've got a VPS with dedicated resources and (apparently) including its own dedicated Windows operating system (I presume that will mean its own IIS as well). I understand I can tell the host to configure it in whatever fashion I prefer. I also understand that if I paid another $30 for remote desktop access then I could even do it myself, but seeing as I don't yet know what I'm doing, I won't.

Given all that... I'm pretty sure that I'm free to configure the server to run lots of separate sites off a single DNN instance in the most efficient manner.... once I've fully understood what that is :)

In my hosting control panel, I can point each domain name anywhere and I have pointed them all to the folder where my DNN440 instance resides. I'm now wondering if having this function in the panel implies that each of the domains has its own app-pool?

Any further advice is very much appreciated. These questions have been at the back of my mind for a couple of years now.

Rob

to anwer you questions:

yes, each IIS instance is mapped to an app pools, dotnetnuke virutalises sites, so as far as app pools are concerned they're the same IIS instance. You could save memory if you point all your IIS instances to the same app pool, but i suspect that's what your host is already done (it's common practice of hosts to create 1 app pool per customer, and to map all customer IIS instances to that app pool, this is a secure practice known as worker process isolation mode )

you may not want to use the same app pool, as only one version of the .net framework can exist per app pool.

I seriously doubt your host is providing seperate app pools per IIS instance as you would rapidly use up all Ram -this would not be economically scalable for a host, unless you have a dedicated server, in which case the only person you inconvenience is yourself.

Beyond this, I cannot answer any of your questions, as they relate to how your host is configured, which I can only guess at. I would suggest emailing their technical help and asking them if all your sites run under 1 app pool.

Cathal

Thanks for the information Cathal, that pretty much explains it for me and no doubt others will also benefit from the thread.

I'm off to read those articles now!

Regards,
Rob