Application Pools and SharePoint Server 2007

Software programs run best when they run on their own dedicated servers. This arrangement eliminates much of the worry about resource contention between programs. On the other hand, protecting program execution through the use of dedicated hardware is a very expensive solution. To provide integrity for resource allocation to individual programs, and to minimize unforeseen consequences due to program interaction, SharePoint Server 2007 structures its Web applications into Internet Information Services (IIS) application pools.

IIS application pools are software containers that function as virtual hosting environments for program instances. A program instance and its allocated resources are known as processes within the Microsoft Windows environment. System resources are allocated to each application pool and then shared between the program instances that are hosted within the pool.

This model provides for the sharing of resources between pools, and between processes within a pool. However, it isolates the processes in one pool from interaction with the processes in another pool. The application pools do not, however, map directly to any hardware configuration; they are not bound to a single CPU or set of CPUs. One CPU can support multiple application pools, and a single application pool can span multiple CPUs. So the application pools isolate applications from applications outside their application pool. They also isolate the application from interaction with the hardware. Therefore, SharePoint Server 2007 Web applications bind to application pools that serve as a virtual hosting environment for processes that result from instantiations of the Web applications.

By default, the Central Administration UI in Microsoft Office SharePoint Portal Server 2007 asks you to create a new application pool each time you create a new Web application. Should you do this? Should each new Web application run inside its own application pool?

One benefit to having each Web application run inside its own application pool is that each Web application enjoys the worker process isolation that each application pool offers. This feature gives your deployment maximum stability, especially if many of your Web applications are running homegrown code that could potentially bring down a Windows SharePoint Services-based application. In addition, any security exploits that would bring down a Web application would need to be replicated across each application pool to be effective in bringing down your entire farm.

To understand the relationship between application pools and Web applications in SharePoint Server 2007, take a look at the application pool architecture.

Application Pool Architecture

A worker process in an application pool is really a single thread that the subsystem uses to process all the pages in the Web applications. A thread is an entity within a process that Windows schedules for execution. It is the smallest unit of code that can be run by itself. A thread includes the contents of a set of CPU registers representing the state of the processor, two stacks (one for the thread to use while executing in kernel mode, and one for executing in user mode), a private storage area for use by subsystems, runtime libraries, DLLs, and a unique identifier called a thread ID. These elements, when combined, are called the thread's context.

In an ideal world, each thread would have its own processor exclusively for its own use. But we don't live in an ideal world, so we have to share multiple threads between one or more processors. The feature of sharing threads across multiple processors is called multitasking and is the operating system's way of sharing a single processor between multiple threads of execution. If the computer has more than one processor, it can process as many threads simultaneously as it has processors. The Windows operating system, by default, can run all threads across all processors, meaning that one processor is not dedicated exclusively to running one or more threads. This is known as symmetric multiprocessing (SMP).

Windows can be configured to assign one or more threads to run on a specified processor. This is known as processor affinity In either case, the memory space for the threads that are run is shared across all the processors, so having multiple processors does not increase the amount RAM (in a virtual sense) on your system, nor does it imply a more efficient use of RAM on your server.

At this point, you need to understand the difference between user mode (UM) and kernel mode (KM) to understand how memory is mapped. These two modes are set up primarily to protect the operating system components from being damaged or hindered by applications that run on top of the operating system.

User application code runs in user mode, whereas operating system code runs in kernel mode. UM applications that call for system services must run through a subsystem .DLL to make their calls for resources. The KM processes retrieve the resources for the UM application. If the UM application needs to manipulate the hardware, such as repainting the screen, the call is proxied to the hardware by KM processes. At no time do UM applications talk directly to the hardware, whereas KM process can and do manipulate hardware directly. KM is a mode of execution in a processor that grants access to all system memory and all CPU instructions. These threads of execution have a higher processing priority than threads that run in UM. KM operating system and device driver code have complete access to system space memory and can bypass Windows security to access objects.

A program is a static sequence of code instructions. A process is a container for a set of resources that are used when executing an instance of the program. A process can be run in either UM or KM, but it will contain all the supporting environment structures that a thread needs to run. Other supporting environment elements that need to be in place when a process runs a thread include items such as communication ports, files, and semaphores. (A semaphore is essentially a counter that allows a maximum number of threads to access the resources of the process that are protected by the semaphore.) A process also contains a set of virtual memory addresses that the process can use, a process ID (seen in Task Manager), and at least one thread of execution.

It is important to understand that every thread within a process shares the process's virtual address space, meaning that all the threads in a process can write to and from each other's memory. The overall size of the virtual address space varies for each hardware platform, but for 32-bit, X86 systems, the maximum is 4 GB. By default, Windows allocates half of this address space to UM processes and the other half to KM processes.

If you have 4 GB of RAM, you can boot the server (Windows 2000 Server with SP2 and later) with the /3GB switch and the /USERVA switch. The net effect of using the /3GB switch is that 3 GB of the memory address spaces are reserved for UM processes, leaving 1 GB for KM processes. The advantage of using the /USERVA switch is that you can specify a value between 2048 and 3072 and that amount of RAM will be given to UM and the balance left for KM. The /3GB switch must also be used, but you can throttle the UM memory space to be 2.5 GB, for example, instead of having to choose between 2 GB or 3 GB when booting the system. These switches are applied to the boot.ini file.

One of the attractive things about running in a 64-bit environment is that the overall address space for processes increases from 4 GB to 7152 GB. If you're running in a 64-bit environment (and more SharePoint servers are these days), Windows Server provides a way to map the 32-bit memory spaces to a 64-bit virtual environment. This feature is called Address Windowing Extensions (AWE), and it allows a 32-bit application to allocate up to 64 GB of physical memory and then map views or windows into its 2-GB address space. Note that IIS 6.0 has a Large Memory Support feature that enables you to cache up to 64 GB of memory on a traditional x86 system.

An application pool will have, by default, one process assigned to run in UM. You can increase the number of worker processes that will be run and configure a Web garden. A Web garden is an application pool that uses more than one worker process. But don't let the word "pool" fool you: each process will get its own set of supporting elements that it needs to be a complete, independent process, including its own memory space. The main advantage of a Web garden is that each process provides independent access to the Web application. This means that if one process is either busy (for example, servicing a backup request) or blocked, the other processes can answer calls and give the clients access to the Web application. This increases the stability of the Web application, but it also uses more memory because each process gets its own memory address space as part of its context.

Discussion of Application Pool Architecture and SharePoint Server 2007 Integration

Now that you've gone through a bit of operating system architecture, come back to the question of how many Web applications can you associate with a single application pool.

First, you need to do some performance monitoring of the process that runs your SharePoint threads. This will be the worker process (w3wp.exe) that is associated with the application pool hosting your Web applications. You need to know how much memory these processes are consuming on average. There will always be spikes and valleys, but the overall average is what you're after.

Next, you need to decide if you're going to run the /3GB switch and perhaps the /USERVA switch to allocate more of the 4-GB address space to UM, which is where SharePoint runs. Because application pools run in UM, you can easily conclude that SharePoint Server 2007 also runs in UM. Increasing the amount of RAM that is available to the application pool also increases the user demand that each application pool can handle via increased maximum memory limit configurations in the properties of the application pool.

Finally, if you've never run SharePoint and are trying to predict the future without any past history, make an educated guess based on performance monitoring of other Web sites you might have that have experienced similar demand.

Here are some tips for designing your SharePoint implementation:

• Do not run more than 10 Web applications per application pool until you have some performance monitoring experience behind you and you can point to your own numbers, which tell you that your application pools can handle more virtual servers.

• Do not plan to run more than 20 Web applications on a single physical server without adding a second Web server (or more) in your farm. The reason for this is because if you're running 20 virtual servers, you've got a growing, busy farm and chances are good that you should scale out before you scale up.

• Always purchase servers with 4 GB of RAM to give yourself maximum flexibility in memory allocation for your application pools.

• Make each application pool a Web garden with two or three worker processes associated with it. When stsadm.exe runs, it locks one of the threads for its own use. Having other threads available to service calls during backup/restore operations or other scripted operations using stsadm is necessary in most environments. In addition, if a thread becomes very busy, the other threads can pick up the slack.