SharePoint 2010 - Why lots of web applications will hurt you

Intro

I know this post is probably somewhat dated but if I can save those that will be deploying SharePoint 2010 instead of SharePoint 2013, this article is extremely relevant. It also might add additional weight to why we have decreased the # of web applications supported in SharePoint 2013. Yes, "Host Name Site Collections" are the answer in SharePoint 2013! See my blog on a complete guide to SharePoint 2013 host name site collections here. We have a "supported" limit of up to 100 web applications in a SharePoint 2007 farm. In SharePoint 2013, we have a supported limitation of 20 web applications per farm. As of 11/5/2013, We have no documented supported limits on the # of SharePoint web applications in a SharePoint 2010 farm. We do have a limitation on up to 10 application pools on a given SharePoint 2010 server. This particular limitation makes since in that you are putting a soft cap on the amount of resources consumed by all w3wp processes. However, this documented limitation for SharePoint 2010 doesn't stop one from provisioning a large # of web applications and share application pools.

 

Why is it bad?

Simply put, your patching times will suffer. To be more specific, each web application is backed by an individual IIS Site. If that web application is extended, your now using two iis sites. Imagine if a SharePoint 2010 farm consists of 40 web applications all extended. That means each Web Front end or SharePoint server with the logical service instance "Microsoft SharePoint Foundation Web Application" started will be hosting 80 iis sites. After patching SharePoint 2010 by applying a cumulative update, PSConfig must run on every SharePoint box in the farm. During PSConfig, we run the SPIisWebSiteWssSequence which iterates through every single IIS site in order to stamp the version info.

Question: How can I prove this is happening?
Answer: Simply look at the buildversion for the IIS Site.

 

Before April 13 CU

 

After Oct 13 CU Applied with PSConfig

 

While this is a light weight operation which takes around 30 seconds per IIS site, it's compounded when a large # of IIS sites must be traversed. Let's take the above example of 40 web applications all extended which means 80 IIS sites.

80 IIS sites * 30 second processing time = 2,400 seconds
2,400 seconds\ 60 seconds = 40 minutes

Yes, that means each SharePoint Server with the "Microsoft SharePoint Foundation Web Application" service instance started takes 40 minutes to run the SPIisWebSiteWssSequence during PSConfig. After testing this in my lab, the remaining time PSConfig spent through the various other sequences was 7 minutes! So a total PSConfig time of 47 minutes per server with 40 of those minutes stamping the IIS sites via the SPIisWebSiteWssSequence.

Assuming a company is using a large # of web applications all extended as demonstrated in the example, it's likely multiple Web Front Ends are provisioned. Let's assume four web front ends are provisioned for a farm.

PSConfig Time of 47 minutes * 4 WFE = 188 minutes.

Since PSConfig must be run synchronously (one server at a time), were looking at a total patching outage time of 188 minutes or 3 hours and 8 minutes! This doesn't take into account PSConfig outage times of other SharePoint servers that don't have the Microsoft SharePoint Foundation Web Application service provisioned. This also doesn't take into account content databases that require upgrade (see next section).

 

What if I have the databases detached?

First, During the patching process the first box that runs PSConfig will upgrade the schema of the content databases attached. It upgrades them in a serial fashion so when dealing with a large # of content databases, this can add a large amount of time to the overall patching cycle. To make patching more efficient, it's possible to first detach the content databases, patch the boxes, run PSConfig on all of the servers, then start mounting the databases in batches since multiples can be upgraded at the same time. The question posed is does having the databases detached improve PSConfig times specifically around the SPIisWebSiteWssSequence. The quick answer is absolutely not. While the databases are detached, the IIS sites remain and are still processed during PSConfig.

 

Conclusion

At the end of the day, a Company will spend a lot of man hours and money maintaining an environment with a large # of web applications (IIS sites). So regardless of the version of SharePoint your running, consider deploying a small # of web applications. If you've already provisioned a large # of web applications, consider consolidating.

 

Thanks,

Russ Maxwell, MSFT