I’m honoured to be one of the speakers at the upcoming SharePoint Connections 2010 event in Amsterdam, The Netherlands on the 18th and 19th January. It promises to be a great show with lots of great 2010 content and speakers. The general goal of the event is to deliver highlights from the SharePoint Conference earlier this year in Las Vegas to the European audience as well as offering significant networking opportunities. Its all going down at the RAI conference centre just outside Amsterdam city. The RAI isn’t a casino, but it is an excellent conference facility!
I will presenting the following sessions:
- MSC27: Claims Based Identity in SharePoint 2010
You will learn about the major investments in Claims based Identity in SharePoint 2010. You will understand how to use SharePoint in an heterogeneous identity environment for both sign-in and services (SOA). We will discuss the new identity architecture, learn about all the components and how to manage and operate them. In addition, we will go over the design decisions you will need to make as you plan the interop between SharePoint and external systems/web services. - MSC34: Implementing Multi-Lingual Solutions on SharePoint 2010
This session will discuss key success strategies for building multilingual Internet, extranet or intranet sites leveraging Variations and the new Multi-lingual User Interface. Key topics covered include: 1. Core technical concepts 2. Planning considerations 3. Information architecture and site structure 4. Hierarchy creation 5. Variations logic 6. Navigation and Web Parts 7. Multi-lingual User Interface benefits. - MSC12: Scaling SharePoint 2010 Topologies for Your Organization
Now that you learned about the new SharePoint Service architecture, come learn about how you architect Services for your organization. We will talk about various Canonical SharePoint deployment types (Internet Presence, Partner Collaboration via Extranets, distributed/consolidated data centers, medium sized organization etc.) and describe how you architect the Services logical topology. In addition to the logical topology, we will drill into how you scale-up/scale-out the physical topology to meet the scale expectations for your organization. Regardless of the nature and scale of your organization, SharePoint 2010 now offers a topology for you!
Along with my partner in crime, “The Doc”, Neil Hodgkinson, I will also be delivering an all day post conference workshop for IT Pros on the 20th January.
- MPS01: SharePoint Server 2010 Administration Workshop
Prepare yourself for the new world of SharePoint Server 2010 Administration! Come and spend a full day with SharePoint Certified Masters Spencer Harbar and Neil Hodgkinson as they cover the administration and operations fundamentals of SharePoint Server 2010. They’ll cover the gotchas of the install as well as potential pain points you might encounter when upgrading in your organization. After this workshop, you’ll have the key information you will need to install, upgrade, operate and manage SharePoint Server 2010 beta up and running in your organization.
There will also be a SharePint on the Monday evening to mingle with the SharePoint community, and also partake in some real beer. Yes, that’s right – real beer (made in Europe!) at a SharePoint event. Whatever next?! Check out the event site for more information and registration details.
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.