IIS 7 Application Pool Guidance
Hi All
I am looking for some guidance on application pool usage within Server 08, IIS7 and .NET 2.0 (if it helps the server is a dual quad core xeon 2.6 with 8gb ram and fast HDD's)
On our server we have approximately 100 sites. They all use a common DLL and set of files. Each website is configured with locally relevant files in d:/webfiles/websitename/ww
Then each website has a virutal directory that maps to a d:/webfiles/common/ folder. The application runs locally and within the shared virtual directory.
All websites and virtual directories are currently using the same "Default Application" pool setup in IIS. We also have DLL's running the Global Assembly Cache, but I believe this is of no consequence here.
My question is, which is a better setup in terms of performance and resiliancy?
1 website = 1 application pool serving the local website and virtual directory?
or
Stick with current layout mapping all websites and VD's to the same Application Pool?
I know that each website and virtual directory must use the same app pool because of the way our virtual directory utilises session management with the Common directory. I am happy with running it 1 website, 1 app pool.
However, my thoughts are for every application/virtual directory running the Application Pool (whether individual or shared) must load into memory a copy of that DLL and other managed code. It must then also swap memory and process requests all inside the same shared piece of memory and worker process (possibly only utilising one CPU?).
Are there limitations on how many requests a single work process can handle, and would it be more efficient to let each website have its own worker process and utilise the 8 core's and 8gb of memory more efficiently? Would it make a difference?
Thanks for your help.
I am looking for some guidance on application pool usage within Server 08, IIS7 and .NET 2.0 (if it helps the server is a dual quad core xeon 2.6 with 8gb ram and fast HDD's)
On our server we have approximately 100 sites. They all use a common DLL and set of files. Each website is configured with locally relevant files in d:/webfiles/websitename/ww
Then each website has a virutal directory that maps to a d:/webfiles/common/ folder. The application runs locally and within the shared virtual directory.
All websites and virtual directories are currently using the same "Default Application" pool setup in IIS. We also have DLL's running the Global Assembly Cache, but I believe this is of no consequence here.
My question is, which is a better setup in terms of performance and resiliancy?
1 website = 1 application pool serving the local website and virtual directory?
or
Stick with current layout mapping all websites and VD's to the same Application Pool?
I know that each website and virtual directory must use the same app pool because of the way our virtual directory utilises session management with the Common directory. I am happy with running it 1 website, 1 app pool.
However, my thoughts are for every application/virtual directory running the Application Pool (whether individual or shared) must load into memory a copy of that DLL and other managed code. It must then also swap memory and process requests all inside the same shared piece of memory and worker process (possibly only utilising one CPU?).
Are there limitations on how many requests a single work process can handle, and would it be more efficient to let each website have its own worker process and utilise the 8 core's and 8gb of memory more efficiently? Would it make a difference?
Thanks for your help.
ASKER
Hi,
Can you pass any comment on the usage of the CPU cores and app pools, would I be right in saying that if you share a single app pool that app pool can only utilise 1 of the available 8 cores on my server?
Also would it cause performance issues with it only using that one piece if allocated memory.
I am confident it is better for redundancy, however performance is also a big concern.
Thanks for your help
Anthony
Can you pass any comment on the usage of the CPU cores and app pools, would I be right in saying that if you share a single app pool that app pool can only utilise 1 of the available 8 cores on my server?
Also would it cause performance issues with it only using that one piece if allocated memory.
I am confident it is better for redundancy, however performance is also a big concern.
Thanks for your help
Anthony
Hi,
you can set processor affinity for individual application pools, if you want to - check out SmpAffinityMask settings.
>> would I be right in saying that if you share a single app pool that app pool can only utilise 1 of the available 8 cores on my server?
only if you /intend/ to do that.
cheers.
you can set processor affinity for individual application pools, if you want to - check out SmpAffinityMask settings.
>> would I be right in saying that if you share a single app pool that app pool can only utilise 1 of the available 8 cores on my server?
only if you /intend/ to do that.
cheers.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi
In terms of interacting with each other, the Websit Root & Common virtual directory (found inside every website) uses the same app pool. This is required as you said to ensure session data etc is transferred. No data is transferred cross domain, only within the /root and /common folder of each website.
So to try and acheive a solution for me...
What would you suggest. Bearing in mind 150 completely seperate websites. But all utilising the same DLL in seperate applications. This means if i set it up al usng same app pool, there would be 150 applications all loading and using a copy of the same DLL into that app pool.
All in one? or Each website in seperate app pool?
Bearing in mind i am trying to acheieve a good balanc between performance and resiliancy.
Thanks
Anthony
In terms of interacting with each other, the Websit Root & Common virtual directory (found inside every website) uses the same app pool. This is required as you said to ensure session data etc is transferred. No data is transferred cross domain, only within the /root and /common folder of each website.
So to try and acheive a solution for me...
What would you suggest. Bearing in mind 150 completely seperate websites. But all utilising the same DLL in seperate applications. This means if i set it up al usng same app pool, there would be 150 applications all loading and using a copy of the same DLL into that app pool.
All in one? or Each website in seperate app pool?
Bearing in mind i am trying to acheieve a good balanc between performance and resiliancy.
Thanks
Anthony
Hi,
I maintain that it is /always/ preferable to separate your applications into independent pools. the only reason that you would not do it is because you don't want to. You might not want to if you have lots of low-utilisation applications and you want to share resources for them all.
Regarding sharing of session information between applications, there are two comments that I would like to make:
1. you will only share session information if the applications are accessed by the same hostname - the browser will not submit the session cookie between web sites (that is a security requirement)
2. if you are sharing session data, then they are arguably the same application. If you really need to share data between applications, then session data is not the way to do it anyhow.
I don't understand why access to a single dll would require only one application pool. If the dll is constructed properly thread-safe, then it should not make any difference if it is accessed via one application pool or many.
Cheers!
I maintain that it is /always/ preferable to separate your applications into independent pools. the only reason that you would not do it is because you don't want to. You might not want to if you have lots of low-utilisation applications and you want to share resources for them all.
Regarding sharing of session information between applications, there are two comments that I would like to make:
1. you will only share session information if the applications are accessed by the same hostname - the browser will not submit the session cookie between web sites (that is a security requirement)
2. if you are sharing session data, then they are arguably the same application. If you really need to share data between applications, then session data is not the way to do it anyhow.
I don't understand why access to a single dll would require only one application pool. If the dll is constructed properly thread-safe, then it should not make any difference if it is accessed via one application pool or many.
Cheers!
I agree ... seperate app pools is the preferred way to go.
meverset,
in your comment you identified the reason why you MIGHT need to do a single app pool ... "If the dll is constructed properly " ... IF being the operative word. I've worked with too many apps and programmers to assume that it is. This would need to be tested and verified.
meverset,
in your comment you identified the reason why you MIGHT need to do a single app pool ... "If the dll is constructed properly " ... IF being the operative word. I've worked with too many apps and programmers to assume that it is. This would need to be tested and verified.
ASKER
Can a single app pool utilise more than one processor?
Is there a limit on the amount of memory a 64bit worker process can utilise?
Anthony
Is there a limit on the amount of memory a 64bit worker process can utilise?
Anthony
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I believe that the question has been fully answered by the two expert participants.
it is always best to isolate applications into independent app pools. When the applications are small or seldom used, then it is OK to group them into a single pool.
the idea of seperation is so that when there is a problem with any application, it does not affect any other one. The idea of sharing an application pool is to reduce resource overheads when there are a large number of relatively low demand apps.
at the very least, you should make a seperate application pool per customer (or per web site)
cheers.