I have a website that a number of customers are using to host their sites. They each have their own domain name, but are using the same hosted service. Is it better to have them run off the same IIS website with all the host headers on that site, or should I create a different website & app pool for each domain that point at the same physical directory on the server?
-
We're just about to run this kind of setup. Are you using the host headers to decide which config file to apply/database to look at or is it determined by logon? – jammus Apr 30 '09 at 08:15
-
At this point it will be using the same DB too, the host header will map to a site ID in the DB, which will be combined with logon to determine who can see what – Glenn Slaven Apr 30 '09 at 08:25
3 Answers
No reason to use multiple app pools unless you have an explicit reason for separating them. Otherwise it's just waste of memory.
There shouldn't be any issues in running multiple websites off the same directory. If at some point a client needs a different version, you can migrate them onto a different dir with a specialized code base / config / etc. If this is a scenario that might occur more often, then you might consider separating them onto different websites up front.
- 2,108
- 2
- 21
- 31
There are no problems with running multiple sites from the same folder, I have done it many times. The advantage you gain by running separate sites in separate app pools is resilience to crashes, if an error is caused in one site, it is less likely to affect the others. It also means that if one site is more popular than the others you can alter the pool settings to make that more efficient when recycling threads if required.
- 38,158
- 6
- 77
- 113
In some cases it might be dangerous. There is a possibility to get deadlocks on file system resources. In my case it was lucene index and two app pools looking to the same folder. Both started index update simultaniously, so half of files were locked by one application and another half by second one, caused both web sites unresponsivness. Extremly hard to debug.
- 1