An application pool serves as a container for your applications in IIS. It's a collection of one or more URLs that can be served by a worker process, and it provides isolation: applications that run on one application pool are in no way affected by other applications that run on different application pools. This level of isolation provides the necessary protection boundary and makes your application secure. A good understanding of what application pools are and how they work is essential for configuring your IIS the correct way.
A worker process in the context of IIS is one that can execute web applications and is responsible for handling the requests specific to a particular application pool. Note that an application pool that contains multiple worker processes is known as a Web Garden, and that an application pool can have one or more applications, each of which shares the worker process.
Microsoft says: "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."
You can have multiple applications residing in an application pool with each of them sharing the worker process. You can have several applications share the same worker process, or, one worker process per application. Having multiple applications share the same worker process has it pros and cons. When each application runs on its own worker process, the failure of one application doesn't affect the other. However, if your applications share the same worker process, making configuration changes are seamless. The main disadvantage of this approach is that if the worker process is down, it would crash all the applications. Also, all the applications that leverage the same worker process would share the same security profile.
Creating and configuring an application pool
To create an application pool in IIS, open IIS Manager, select "Application Pools" feature pane, right click on it and then click on "Add Application Pool...". Alternatively, you can also create an application pool using PowerShell. I will discuss on how this can be done in one of my future posts here.
There are two pipeline modes in IIS 7 and onwards: classic mode and integrated mode. In the classic mode, IIS works with ISAPI extensions and ISAPI filters directly and the IIS and ASP.Net request-processing models are separated. The Classic Pipeline mode works similar to IIS 6.0. On the contrary, in the integrated mode, the request processing models of both IIS and ASP.Net are integrated into a unified process model. In this mode you can leverage the request-processing architecture of IIS and ASP.Net. This unified processing pipeline is exposed to both native and managed components alike. In essence, in the integrated mode, IIS and ASP.Net are tightly coupled to each other.
When you explore the advanced settings option of an application pool, you would find many options. You can specify the version of .Net CLR you would like to use. You can also enable 32 bit applications using the "Enable 32 Bit applications" option. The "Managed Pipeline Mode" option enables backward compatibility. You can set the queue length using the "Queue Length" option. The "Limit", "Limit Action" and "Limit Interval" options enable you to specify throttling settings. The "Identity" option is used to specify the user that your application pool would be impersonating. With IIS 7, you can run your application pool with "ApplicationPoolIdentity" account. This is the recommended option although you can also run your application pool under a specific user's account as well.