Dear followers,
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:
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:
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 harber.net) 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.
