An application pool is a group of one or more URLs that are served by a worker process or a set of worker processes. Application pools set boundaries for the applications they contain, which means that any applications that are running outside a given application pool cannot affect the applications in the application pool.
Application pools offer the following benefits:
Most managed applications should run successfully in application pools with integrated mode, but you may have to run in classic mode for compatibility reasons. Test the applications that are running in integrated mode first to determine whether you really need classic mode.
http://technet.microsoft.com/en-us/library/cc753449(v=ws.10)
You can monitor and improve application pool health by having the Windows Process Activation Service (WAS) ping an application pool's worker process at set intervals.
A lack of response from the worker process might mean that the worker process does not have a thread to respond to the ping request, or that it is hanging for some other reason. Based on the results of the ping request, WAS can flag a worker process as unhealthy and shut it down.
By default, worker process pinging is enabled. You may have to adjust the ping interval and the ping response time to gain access to timely information about application pool health without triggering false unhealthy conditions, for example, instability caused by an application.
The identity of an application pool is the name of the service account under which the application pool's worker process runs. By default, application pools operate under the Network Service user account, which has low-level user rights. You can configure application pools to run under one of the built-in user accounts in the Windows Server® 2008 operating system. For example, you can specify the Local System user account, which has higher-level user rights than either the Network Service or Local Service built-in user accounts. However, remember that running an application pool under an account that has high-level user rights is a serious security risk.
You can also configure a custom account to serve as an application pool's identity. Any custom account you choose should have only the minimum rights that your application requires. A custom account is useful in the following situations:
Application pools offer the following benefits:
- Improved server and application performance. You can assign resource-intensive applications to their own application pools so that the performance of other applications does not decrease.
- Improved application availability. If an application in one application pool fails, applications in other application pools are not affected.
- Improved security. By isolating applications, you reduce the chance that one application will access the resources of another application.
Most managed applications should run successfully in application pools with integrated mode, but you may have to run in classic mode for compatibility reasons. Test the applications that are running in integrated mode first to determine whether you really need classic mode.
http://technet.microsoft.com/en-us/library/cc753449(v=ws.10)
You can monitor and improve application pool health by having the Windows Process Activation Service (WAS) ping an application pool's worker process at set intervals.
Note |
---|
Worker process pinging differs from Internet Control Message Protocol (ICMP) pinging. Instead, it uses an internal communication channel between the WAS and the worker process. |
By default, worker process pinging is enabled. You may have to adjust the ping interval and the ping response time to gain access to timely information about application pool health without triggering false unhealthy conditions, for example, instability caused by an application.
The identity of an application pool is the name of the service account under which the application pool's worker process runs. By default, application pools operate under the Network Service user account, which has low-level user rights. You can configure application pools to run under one of the built-in user accounts in the Windows Server® 2008 operating system. For example, you can specify the Local System user account, which has higher-level user rights than either the Network Service or Local Service built-in user accounts. However, remember that running an application pool under an account that has high-level user rights is a serious security risk.
You can also configure a custom account to serve as an application pool's identity. Any custom account you choose should have only the minimum rights that your application requires. A custom account is useful in the following situations:
- When you want to improve security and make it easier to trace security events to the corresponding application.
- When you are hosting Web sites for multiple customers on a single Web server. If you use the same process account for multiple customers, source code from one customer's application may be able to access source code from another customer's application. In this case, you should also configure a custom account for the anonymous user account.
- When an application requires rights or permissions in addition to the default permissions for an application pool. In this case, you can create an application pool and assign a custom identity to the new application pool.
No comments:
Post a Comment