Print | posted on Wednesday, December 02, 2009 1:23 PM
Recently a number of people have asked about the number of worker processes which are alive on a new install of SharePoint Server 2010 and the associated other processes which amongst other things increase the resource requirements (primarily RAM) for running SharePoint 2010 over SharePoint 2007. This post will explain the core changes here and what you can expect to see following the installation and farm configuration.
As with SharePoint 2007, or any other .NET based web application for that matter, your implementation specifics will determine the number of and isolation and security characteristics of the processes running including those that are governed by IIS Application Pools. However SharePoint 2010 does make a number of key changes to be aware of to the partitioning of application pools and therefore their associated worker processes. These changes are not for the sake of it, but rather to lay the foundation for a more robust provisioning and “enterprise ready” platform as well as supporting new features in the product.
As mentioned above, the exact characteristics of your environment such as how you choose to deploy Web Applications and Service Applications will determine the application pools and worker processes on your machines. For the purposes of this explanation it is assumed that you have installed SharePoint Server 2010 on a single machine, and have used the SharePoint Configuration Wizard to create a farm, and the Farm Configuration Wizard to setup your Service Applications and initial Content Web Application. It is further assumed that you have used the default settings to provision all available Service Applications, but not the Office Web Applications.
For this type of setup we will make use of two Service Account Identities, as detailed below:
| SharePoint Farm Account | SPFarm |
| SharePoint Service Applications Account | SPServices |
Once we have run the SharePoint Configuration Wizard to create the Farm, and run the Farm Configuration Wizard to provision our Service Applications, will we have the following Application Pools, which govern a single worker process each (Web Gardens are still not supported/recommended/sensible with SharePoint 2010).
- SharePoint Central Administration v4
Identity: SPFarm - The SharePoint Topology Service Application (the app pool name in IIS is a GUID, in SharePoint it is SharePoint Web Services System)
Identity: SPFarm - The SharePoint Security Token Service Application (the app pool name in IIS is a GUID, in SharePoint it is SecurityTokenServiceApplicationPool)
Identity: SPFarm - All the other SharePoint Service Applications (the app pool name in IIS is a GUID, in SharePoint it is SharePoint Web Services Default)
Identity: SPServices - SharePoint – 80 (the “Default” Content Web Application created by the Farm Configuration Wizard)
Identity: SPServices
The first three application pools can be considered core or Farm elements, and are present after the SharePoint Configuration Wizard is completed, whereas the last two can be considered Service elements which are present after the Farm Configuration Wizard is run. You can of course use the same account for both the Farm and Service elements, but you will still have five application pools. I strongly encourage that you use separate accounts and practice good platform hygiene. You will not gain performance improvements by using the same account.
In most cases, in a test rig type deployment and/or a development box, two of the above application pools will rarely be spun up, and this is why you will often only see three w3wp.exe worker processes in task manager. The Topology Service will only usually be alive when servers are being added to the farm, Service Applications are being grouped/created and/or Services on Server is being configured. Once you have setup your development box, it is highly likely you will never see this guy fire during normal operation. In a real world environment this is not the case as this guy also takes care of application discovery and “load balancing” of service application requests. The Security Token Service Application (STS) is more likely to fire as this is necessary for internal service interactions, but while the worker process is alive there often will be zero running requests.
So we have more (five) worker processes than we did in SharePoint 2007 (usually two). These all consume resources and contribute to the additional RAM requirements for SharePoint 2010. But this is a good thing! Functional decomposition of services is a primary tenant of distributed application architecture sadly all to often overlooked or ignored.
The Topology Service Application (aka Application Discovery and Load Balancer Service Application) being isolated will lead to faster and more reliable farm topology operations, especially in very large farms, and could also be considered a pre-requisite for multi-tenant scenarios. And the STS absolutely *has* to be isolated or it wouldn’t have any credibility whatsoever given it’s role!
I’m not a big fan (putting it mildly) of the way the Farm Configuration Wizard uses the account entered (SPServices in this example) as the Application Pool Identity for the Default Content Web Application, but the wizard is there to get deployments up and running quickly using lowest common denominator defaults. In the real world, on a real farm you are unlikely to be using this wizard at all. And this leads on to some other aspects of this default install/config that also impact the resource requirements for SharePoint 2010.
By configuring all the Service Applications by default you will have other processes running, the best example of which is the Web Analytics Service which will gobble up 90Mb even when it’s idle. In addition if you go ahead and also start some other SharePoint Services from Services on Server (e.g. the User Code Service, aka Sandbox) you will also get more processes (obviously). If you want good performance in RAM limited test/dev environments, especially in VMs don’t be starting Service Applications or SharePoint Services that you don’t need for the current task or project.
Hopefully the above adequately explains why we have more worker processes by default in SharePoint 2010. I’ll be covering more in depth details of process isolation, functional decomposition and farm topology over the coming months.