Planning application pools
As you will discover in the planning for software boundaries section, there is a supported limit of 10 application pools per web server.
At first, it would seem that this number might be some sort of mistake; you see, if you were to build a basic SharePoint farm and run the Farm Configuration Wizard from Central Administration, you would see from IIS Manager that there are already 12 application pools in service before you’ve built your first web application.
Let’s set aside the limits discussion for a moment and talk about what an application pool is used for.
how is an application pool used?
An application pool is a construct used to group web applications logically, based on a number of criteria such as authentication, performance, isolation, and configuration. Web applications contained in an application pool provide functionality for one or more web sites in an IIS farm.
Confused yet? Let’s take a look at a SharePoint-specific example of how application pools, web applications, and sites interact.
If you build a SharePoint farm, activate the default service applications (manually or via the Farm Configuration Wizard) and then build the first site (using the defaults provided). You wind up with several application pools, even more web applications, and a few SharePointspecific web sites (see Figure 1-26).
FIGURE 1-26 Application pools supporting a SharePoint farm.
Looking at these application pools, we see that there is a SharePoint - 80 application pool. Filtering on this pool (by right-clicking the app pool and selecting view applications), you see that this pool hosts a single application for the SharePoint - 80 site (see Figure 1-27).
FIGURE 1-27 The root web application for the SharePoint - 80 site.
There is also another application pool that hosts a different application but is also providing services to the SharePoint - 80 site. Filtering instead on the SecurityTokenServiceApplicationPool, you see that it is linked to the SharePoint - 80 site as well as to the Central Administration and SharePoint Web Services sites (see Figure 1-28).
FIGURE 1-28 The SecurityTokenServiceApplicationPool and its associated sites.
Web application pool limits guidance
As a rule, you should seek to minimize the number of web application pools. Software boundary and limits guidance (which is covered shortly) states that no more than 10 web application pools exist in a farm.
There are two core reasons for this limitation: available random access memory (RAM) and usage characteristics.
Each web application pool adds about 100–200 megabytes (MB) of overhead to begin with plus the amount of memory required to run each site in the pool.
Before you add a new pool, consider whether an existing pool can be used to host any new web applications. The number of pools might not initially be an issue, but as SharePoint usage grows within your organization, you might find that the web servers in your farm begin to run short of available RAM.
A heavily trafficked web application pool can quickly generate a RAM load that can grow into the multigigabyte (GB) range (sometimes exceeding the 10 GB mark).
Considerations for building web applications
You might want to build a new web application pool for any of the following reasons:
■■ Grouping web applications that run with the same configuration settings
■■ Isolating web applications that require unique configuration settings
■■ Providing security by running a particular group of web sites under a closely monitored service account for auditing purposes ■■ Resource isolation:
■■ To prevent an outage of the entire IIS application based on one or more misbehaving or failed web applications
■■ For ISPs to separate application pools based on customer resource needs
Before adding a new web application, consider using Performance Monitor (perfmon.exe) to get a baseline of existing RAM usage. Monitoring a SharePoint environment is a topic that is covered in Chapter 5, “Maintain a core SharePoint environment.”
