Wednesday, 4 August 2010

WFE Application Pool Limitations in SharePoint 2010 (Part 2)

Recent related blogs that might interest you:

16/02/2010 Update: Having recently been to a SP2010 admin course with Combined Knowledge, I took the opportunity to discuss this with @SteveSmithCK who has suggested that for now we should ensure farms are in a supported state and stick to the MS documented limit of 10 app pools in total (i.e. Portal content AND Service app end points). I will update this post if Microsoft do change the SP2010 software boundaries Technet article to clarify this point. I would say that the article is currently ambiguous and open to interpretation - especially given that it states that "The maximum number is determined by hardware capabilities". Only the Microsoft product team can really answer this question once and for all.

22/12/2010 Update: Note that this blog post refers to application pools used for hosting content Web applications only, NOT those hosting service application end-points. This article by @jremmc explores the differences between the two - check it out!

A couple of weeks ago I blogged about the application pool limitations in SharePoint 2010 based on a discussion I had with @SteveSmithCK at the #SUGUK. Since then, I have been on vacation in Iceland and received a number of related comments from members the SharePoint community. You can read the original post here; in this post I will aim to provide a concise summary with some revised best practise recommendations.

The key points, which were kindly sent to me by @SteveSmithCK and @harbars are that:

  1. The TechNet recommended maximum number of Web server applications pools is 10, which is correct.
  2. The IIS 7.5 limit of 100 pools with Windows Server 2008 R2 x64 is correct - but that limit is not applicable to SharePoint as there are so many other factors to consider.
  3. The point of scale in a Sharepoint farm is not simply the Web servers, but rather a combination of factors including farm usage, number of servers and hardware capability.
  4. Administrators should be questioning why a large number of application pools / Web applications is required, as opposed to why there is a recommended limit of 10.

Both Steve and Spencer made a point of emphasising that performance issues will likely be encountered even before 10 application pools is hit: "If you had 5 App pools all busy then you could easily consume 24GB+ of memory and all four cores very easily on a 64bit WFE Server". So although 10 is the documented figure, it is neither a "magic number" nor a hard limit imposed by the software and depends largely on farm usage (think user requests and service applications, particularly resource hogs such as Performance Point).

Although probably a topic for a future blog post, I think the fourth point above (from Spencer) is particularly interesting. TechNet document a number of reasons why administrators may wish to create additional IIS 7 application pools including grouping similarly configured sites and isolating those with unique configuration settings or security requirements. In the context of SharePoint, the primary reasons I have come across in the past for additional application pools are:

  • Isolating SharePoint Web applications for security-sensitive clients.
  • Isolating SharePoint Web applications that are prone to problems in order to provide protection from cross-site failure (e.g. features, custom Web parts) due to a shared application pool.

I think that there is some validity in the first point for clients that have very stringent security requirements and expect their data to be completely isolated - we have dealt with clients in the past that have requested separate pool identities as part of their corporate security review. However, one could argue that the new multi-tenancy features in SharePoint 2010 (site subscriptions, service application partitioning, host-named site collections; more over at provide a solution to this problem and should help keep the number of required Web applications to a minimum. Remember that more Web applications always means more timer jobs and higher hardware demands - particularly if using a separate IIS application pool and associated worker process.

I think there will always be a place for an isolated application pool for troublesome sites and applications. Although numerous features in SharePoint 2010 should lead to higher availability (e.g. sandboxed solutions, list and HTTP throttling), I am sure that there will still be occasions where farm-wide custom solutions cause issues (e.g. a problematic Web part deployed to the GAC).

Another reason that IIS sites are typically placed in a separate application pool is differing .NET version requirements. This wasn't really relevant to MOSS given that versions 2.0 through 3.5 used the same version of the CLR (see this post for more information), but could be relevant to SharePoint 2010 going forward if Microsoft release an update that supports ASP.NET 4.0.

To summarise, the TechNet recommended maximum of 10 application pools is correct and great care should be taken in planning the creation of new application pools and corresponding Web applications. SharePoint portal application pools can eat a considerable amount of RAM and can bring down even the meanest Web server if deployed without proper planning. As a best practise, the number of pools and Web applications should be kept to a minimum in order to increase farm performance - I think it's worth remembering that site collections are the unit of scale in SharePoint (2000 per content DB recommended maximum) and the new multi-tenancy features in the 2010 version of the product should be utilised in order to deploy an appropriate (scalable) logical architecture.

I hope that helps to clarify things - thanks to @SteveSmithCK and @harbars for their input on this.

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook


  1. As always in the consultancy world, the answer is "It depends" :)

    And it's never more so true with SharePoint, as there are always so many factors to take into account, which your discussion clearly demonstrates.

  2. This is a great blog. Thanks for all your hard work and the info you give. I am hoping you post again soon.I wish u keep on.

    SharePoint Site Branding

  3. There is something that is not clear to me re this and that is If I deploy a web application to my WFE servers then all the web applications and I assume application pools are distributed by CA to "ALL" WFE servers. I can then selectively go thru and turn them off to reduce load but if I restart any web applications or restart the server then likely these app pools will start again. Seems like a potential huge performance hit

    In a corporate environment with stringent security requirements the very first request is to move WFE servers to the perimeter of the network, So how would I have says some app pools running on sme WFE servers for my corporate Web Apps and some running on other WFE servers for my extranet sites.

    This seems to me the same problem as moving app pools around for performance reasons or at least a effective solution would be the same. Can anyone comment ?

  4. SharePoint at its core is a provisioning engine and will provision all Web applications on all WFE servers. This behaviour cannot be changed - at least not in a supported manner.

    However, you will only experience a performance hit if the Web applications and their containing application pools are being utilised.

    In your scenario, you could for example use DNS request routing to ensure intranet users are directed to your internal WFE server(s) and external users are directed to your extranet sites.

    I am on Twitter (@benjaminathawes) if you want to discuss further.

  5. The point about Microsoft clarification is an important one. On the one hand Spence correctly states in one of his posts that the Service application App Pools do not count to the total of 10 supported content app pools as mentioned in the official MS documentation. The issue for me is that Microsoft themselves have not clarified this yet in their documentation and I think it is just a slight ammendment to the official documentation that is needed for everyone to sing from the same song sheet.

    At the end of day Application Pool requirements are part of the design process and decisions are made based on many criteria such as performance load, isolation, available resources, numbers of servers handling requests, concurrency of user load and scalability of services to name but a few. There is no easy answer to how many you need it needs to be part of your Infrastructure design plan.