Internet Information Services (IIS) Application Pools

An Internet Information Services (IIS) application pool is a grouping of URLs that is routed to one or more worker processes. Because application pools define a set of Web applications that share one or more worker processes, they provide a convenient way to administer a set of Web sites and applications and their corresponding worker processes. Process boundaries separate each worker process; therefore, a Web site or application in one application pool will not be affected by application problems in other application pools. Application pools significantly increase both the reliability and manageability of a Web infrastructure.

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:
  • 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.


An Internet Information Services (IIS) worker process is a windows process (w3wp.exe) which runs Web applications, and is responsible for handling requests sent to a Web Server for a specific application pool.

IIS 6.0 onward worker process isolation modes also enable multiple worker processes to be configured to service requests for a given application pool. This configuration is known as a Web garden.

Worker process recycling is the replacing of the instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker process, or worker processes, that are assigned to an application pool. This helps keep problematic applications running smoothly, and minimizes problems such as memory leaks.

When you set the recycling of worker processes using IIS manager, you also need to take the state management strategy of your ASP.NET application into consideration. Because every time the worker process is recycled, the ASP.NET state information will be lost rendering the application in an invalid state. One alternative to overcome this issue is to maintain state data external to the worker process, such as in a database. However, moving data to an external database to allow recycling can affect server performance in the following two ways:
  • Performance is reduced because of the added data management that is needed to move the data between the application and the database.
  • Recycling flushes any in-process data caches, so the caches need to be rebuilt.
If you have an application pool with applications that depend on state data, you must decide whether or not to recycle the worker processes that are assigned to that application pool. If you store state in the same process as that of IIS, and you don't want the state information to be lost, you must not recycle a worker process using the application pool configuration settings.

Some Precautions:

  • Too many worker processes could slow down the web application.
  • Improper allocation of the resources could slow down the web application performance.
  • Improper tuning of the health monitoring and recycling parameter could slow down the web application performance.

Comments

Popular posts from this blog

Data Bound Controls in ASP.Net - Part 4 (FormView and DetailsView controls)

ASP.net: HttpHandlers

The Clickjacking attack and X-Frame-Options