Currently, on our production IIS web farm, we host about 15 applications in a single App Pool (Default App Pool). There are two websites and about 13 virtual directories.
A colleague has recommended that we change our IIS configuration so each application is a separate App Pool (with identical settings).
Is there any drawback or potential issues to doing this?
Is it possible that ASP.NET applications could have been built with the requirements that they are all within the same App Pool?
I doubt they were built with that requirement in mind unless they rely on shared memory for some reason. Otherwise, for the scenario described...
Pros (of separate app pool):
process isolation (one crash doesn't bring down the others)
less resource contention
more memory available for in-proc sessions, cache
Cons:
more processes, memory, and context switchces
shared cache scenarios no longer available*
*I'm not sure how .NET segregates websites in the same app pool as it pertains to the HttpRuntime cache; for Sessions, "application uniqueness" (1) is determined by:
The physical path on all servers (case sensitive)
The machine key
The instance id
The approot
This is what prevents you from sharing sessions across different websites in the same app pool, for instance; but it might be easier to share cache data though. By and large, the discussion overlaps with the pros/cons of deploying a Web Garden for a specific application (2).
1)
http://support.microsoft.com/?id=325056
http://rodiniz.spaces.live.com/blog/cns!F2A56AAF89A7E43A!658.entry
2)
http://nicholas.piasecki.name/blog/2009/02/on-web-gardens-aspnet-and-iis-60/
Besides the configuration time and (maybe) more memory requirements there is no down side to using more than one App Pool.
(Just to be clear... the memory needed will vary depending on many factors -- but there is a way where 15 apps in one pool use more memory than 15 apps in 15 pools. If each app does not need much memory and the apps are used at different times and infrequently.)
Related
What is difference between application domain and application pool?
I have read many articles regarding these two terminology. but still unable to get proper understanding about them.
Please elaborate it with simple description.
Thanks
IIS process is w3wp;
Every application pool in IIS use it's own process;
AppPool1 uses process 3784, AppPool2 uses process 5044
Different applications in Asp.net will use different
AppDomain;
AppTest1 and AppTest2 are in different AppDomain, but in
the same process.
What's the point to use them?
Application pool and AppDomain , both of them can provide
isolations, but use different approaches. Application pool
use the process to isolate the applications which works
without .NET. But AppDomain is another isolation methods
provided by .NET.
If your server host thousands of web sites, you wont use
thousands of the application pool to isolate the web sites,
just because, too many processes running will kill the os.
However, sometime you need application pool. One of the
advantages for application pool is that you can config the
identity for application pool. Also you have more flexible
options to recycle the application pool. At least right now,
IIS didn't provide explicit options to recycle the appdomain.
An application pool is a group of one or more URLs of
different Web applications and Web sites. Any Web directory
or virtual directory can be assigned to an application pool.
Every application within an application pool shares the same
worker process executable, W3wp.exe, the worker process that
services one application pool is separated from the worker
process that services another [Like starting MS Word and
opening many word documents]. Each separate worker process
provides a process boundary so that when an application is
assigned to one application pool, problems in other
application pools do not affect the application. This
ensures that if a worker process fails, it does not affect
the applications running in other application pools. [i.e]
for Eg., If word document is having issue it should not
logically affect your Excel Sheet isn’t it.
application domain is a mechanism (similar to a process in
an operating system) used to isolate executed software
applications from one another so that they do not affect
each other. [i.e] opening of MS WORD doesn’t affect MS EXCEL
you can open and close both the applications any time since
there is no dependency between the applications. Each
application domain has its own virtual address space which
scopes the resources for the application domain using that
address space.
Thanks to this link
In IIS 7, what is best practice? Should I create an application pool for each application, or should I share an application pool with as much application as possible?
Are there any performance drawbacks or security issues related to one of the options?
Each application pool is an instance of W3wp.exe, a worker process for that site or set of sites. By placing each application in a seperate app pool, you ensure that problems that could potentially cause problems within the app pool do not cause problems with other applications. There is obviously an overhead to operating like this in terms of resources.
So generally, for simple sites and blogs I usually put these in a shared app pool. For more intensive or important applications, I seperate into individual app pools. This is just a guide to how I operate.
I believe IIS7 now creates seperate app pools when you create a web site (not 100% though).
In theory it is better to put each site to its own pool. In practice it takes much more RAM than placing the sites to a single pool. So, on most servers you will see 10-100 pools only, even if there are 1000 sites.
Sharing Application pool is better than creating an application pool for each application for a fixed number of application
You can run as many application pools on your IIS 7 server as you need but this will affect server performance.On the other hand Application pools allow a set of Web applications to share one or more similarly configured worker processes but you should not share an application pool to a lot of application.Because This will affect your server performance too!
So in both way you have to be tactful.
I've been looking at application pools lately, specifically with ASP.NET applications in mind and I've been struggling to find any best practices for use of application pools.
Of course alot depends of the size and scale of your destined apps in regards to memory limits etc, but I was more specifically thinking along the following lines...
If developing relatively small .net apps which need to be deployed underneath an existing site, should I as a best practice be creating a new virtual directory and application pool for each app?
Or should I just run them underneath the sites already present app pool?
Secondly are there any limits to the amount of app pools you can run (realistically and again assuming small apps with memory limits auto-handled and not defined) on a standard web server?
With resilliance and optimisation in mind my initial thought is to create a new v dir and app pool per app under the parent site - I just wondered if anyone has any thoughts on best practice or links that may assist?
Cheers
For resilience, create a separate application pool for each application. That way if an event occurs in one application that causes the pool to stop, it is only THAT application affected, and not any others on your server.
This also helps in terms of security - the application pool controls the identity of the running application. You should only give just enough permissions for the application to run on the machine. If one application requires access to a specific folder on the server, that doesn't mean you should be giving the same access to all of your applications.
I've read recommendations that we should create separate application pools for each asp.net application on our Win2008 server.
We have about 20 apps that would be on the same server. I know this would create 20 separate worker processes which seems very wasteful.
Is it good practice to create separate application pools for each application?
Reposted from ServerFault, "Why add additional application pools in IIS?"
AppPools can run as different identities, so you can restrict permissions this way.
You can assign a different identity to each app pool so that when you run task manager, you know which w3wp.exe is which.
You can recycle/restart one app pool without affecting the sites that are running in different app pools.
If you have a website that has a memory leak or generally misbehaves, you can place it in an app pool so it doesn't affect the other web sites
If you have a website that is very CPU-intensive (like resizing photos, for instance), you can place it in its own app pool and throttle its CPU utilization
If you have multiple websites that each have their own SQL database, you can use active directory authentication instead of storing usernames/passwords in web.config.
Separating apps in pools is a good thing to do when there's a reason, and there are a number of good reasons listed above. There are, however, good reasons not to separate apps into different pools, too.
Apps using the same access, .NET version, etc. will run more efficiently in a single pool and be more easily maintained. Most annoyingly, IIS will kill idle app pools, requiring the pool be recreated on each use. If you isolate infrequently used apps you'll impose an unnecessary startup cost on users. Combining these apps into a single pool will make for happier users when they don't pay the startup cost, happier servers when they don't give memory to multiple processes and CPU slices for them, and happier admins when they have to manage fewer app pools.
I used to have 58 .Net websites and 17 old classic ASP websites on the same IIS7.5 server using separate app pools for each site. I noticed that the IIS compression started failing intermittently, causing the style sheets to be corrupted about 5% of the time. Looking at the task manager on the server, I could see that the server was approaching it's 4GB ram limit- each w3wp.exe process was taking anything up to 100 MB memory depending on how much traffic the site was getting. I then moved all the websites into just 2 application pools (one for .net 4 websites and one for the old classic ASP sites) and the total memory used after doing that dropped from 3.8GB to just under 2.8GB - saving me over 1GB memory space on the server. After the change (and leaving the server running for a couple of hours to get back to normal levels of traffic), the w3wp processes were using 300MB for all the .net websites websites and 20MB for the classic ASP websites. I could re-enable IIS compression again without a problem.
Using separate APP pools is a great idea for many of the reasons mentioned by the other posts above, but it also in my experience causes a much higher memory overhead if you are hosting a fair number of websites on the same server.
I guess it's a trade-off between hardware restrictions and security whether you want to use separate app pools. It's a good idea if you have the resources to do it.
yes, it is a good idea even for 20 applications.
Security. Different app pools running under different accounts.
Isolation. One crashing app won't take down other apps.
Memory (if you are running 32bit). Each app pool will have its own address space. Thus you can address much more memory than a maximum of approximately 2.7GB of usable space for 1 process.
You may choose to periodically restart one not-so-well behaving app without affecting other applications.
If your apps are stable and don't use much memory, then I would say that it's fine to put them in the same app pool. App Pools give you isolation between your applications.
One main reason I consider when creating app pools is the process management. There are other reasons such as security etc.
When an IIS-hosted application crashes it takes down its host process as well. In previous versions of IIS this meant all web activity crashed together. With app pools you can isolate your applications from one another. If one has a memory leak and keeps crashing your other apps will continue to function.
The main benefit of creating different application pools is that you can provide each pool with other credentials. Your 20 applications may communicate with 20 different databases that all need another login. The best practice then is to run each application using a different service account.
I wouldn't worry too much about performance. Most time will probably be spent inside each web application, no matter what process each application is in.
This really depends on the applications, your security model, and how much you trust the applications.
Here are a few things that I always tell people to consider when working with application pools.
Use separate application pools if each application needs different access to system resources. (Can use multiple process accounts)
If an application is a resource hog, mission critical, or an "unknown", it is best to put it in to its own pool to isolate it from the rest of the system
We work as outside contractors for a large corporate client. We are not on-site, so we do not have connectivity to all of their systems. Sometimes during development it is necessary for me to debug an application directly on their development servers. To do that I must be able to attach to w3wp process. When I attach and start debugging, entire process stalls, which affects all of the applications that are in the same process/application pool.
By creating a dedicated application pool and moving my development there, I can easily debug without making anyone's life miserable.
What are pros and cons of having dedicated application pools over keeping web applications in one default app pool?
Pros:
Applications are isolated from each other, unless IIS goes with it, an app pool locking will only take out applications in that pool
Ability to run applications under different ASP.NET runtimes, one pool for 1.1 another for 2.0 if needed
Ability to have different app pool settings for more or less critical applications. For example a corporate website in ASP.NET might want to have the shut down after __ minutes of inactivity bumped up, to prevent unloading because response is critical. Other sites might not need it.
Can secure pools from each other in regards to file access, great for third party, or untrusted applications as they can run under a very restrictive user account.
Cons:
Each application pool has its own bank of memory and its own process, therefore CAN use more resources
Some find it hard to debug the application as you have multiple processes
The primary reason for combining sites in app pools is to conserve memory. There's a large memory overhead in running several w3wp.exe processes. If you have no specific reason for splitting them up, it's better to keep them together.
Dedicated app pools typically will keep problems occurring in one site from effecting the others. If you share app pools across sites, you could bring down all sites on the box when an error condition exists for only a specific site (or app pool).
Also, if you are mixing versions of ASP.Net on the same web server, you will need different app pools per ASP.Net version at a minimum, or do it per website.
I can't think of a good reason not to separate app pools, it is so easy to do.
I agree with Jason.
Also, you can designate different users (such as a Windows account) for different app pools. That enables setting up those users with different permissions in the database. That helps enhance security, and enables tracking which website/user is hitting the database, useful when tracing database performance issues.
If you have separate apppools then you pay a penalty in the initial load time of the first person to visit your site and spin back up the apppool after it recycles.
For example let's say overnight no-one hits your server, IIS will spin down (default 20mins I believe). The first person to visit the server will suffer a delay until the your application has been loaded back into memory.
Depending on how you deploy your site (e.g. release mode etc..) this will either not be a problem or could be annoying.
This is why we are looking into moving to a single apppool/server rather than 1 for each site.