A client is requesting a special web application topology that seems odd to me. In a mid-sized SP2010 farm (two WFEs, two app servers) they will have hundreds of site collections. The requirement is to distribute them among multiple web applications because of expected better utilization of server resources, especially memory.

I'm not aware of such a method to gain better hardware utilization and increase performance. Also, I can't think of a simple way to make all these web apps accessible from a single hostname and port — except using URL mapping on some application proxy like TMG and hence increasing the administration overhead. Also, all site collections will have the same authentication settings and will use the same set of services.

My questions:

  • What are the pros and cons of distributing site collections among multiple web apps just for the sake of performance and/or WFE hardware utilization?
  • Would it lead to a performance gain or loss?
  • Please tag by feature or topic and not by version or product. This helps to attract more attention to your question and keep it relevant. See How do I use tags for general guidelines.
    – Alex Angas
    Commented Aug 31, 2011 at 3:49
  • 1
    I am asking specifically about SharePoint 2010, hence I can't see a valid reason why not to tag the question accordingly. Also, my original title better fits the merit of my question. Commented Aug 31, 2011 at 9:10

3 Answers 3


There are so many better ways to improve the performance and scalability of SharePoint than trying to partition site collections across web applications. If you highly optiimize your logical and physical disk IO for SQL Server, partitioning the site collections across multiple content databases on a single web application may provide less contention and increase parallelism, but I don't think you should partition across multiple web applications.

Here is an article on some performance recommendations for optimizing SQL Server:


  • Hi Chris, thanks for confirming my opinion. We are about to partition site collections across multiple content databases, externalize BLOBs, etc., but the strange request from the customer left we wondering whether I'm already silly :-) In fact, I would actually expect a slight performance decrease, but don't have much time to setup a larger lab scenario to proove it. Commented Aug 26, 2011 at 7:57
  • The main reasoning behind splitting up between multiple web applications should be security boundaries. For example extranet vs intranet. Also note that multiple web applications mean multiple job instances for alot of jobs, so there is definately a performance and especially memory overhead on using multiple webapps Commented Aug 28, 2011 at 17:07

I agree with Chris's statements about performance optimization being possible within a web application, but, there are a number of reasons why you would want to consider using multiple web applications.

Things that I typically think through during planning include:

  • Authentication and User Categories - Internal versus External Users, Classic, Claims, FBA
  • Policies - Blocked File Types, User Policies, SPD and Resource Throttling Settings
  • Service Application Mappings
  • Type of Content

For the Type of Content one there are a lot of things that go into that decision. I almost always put any personal sites on a dedicated web application to separate Personal from Collaboration sites. Depending on the size of the organization it is often neccessary to also separate informal collaboration sites from the more formal Intranet and enterprise resources due to policy differences.

The organization of those sites to Content Databases and how that matches up with the overall DR plan and SLAs is very important to understand. If everything is on a single web application, and presumably if all Content Databases are equal, mananaging or restoring a large system can be very difficult.

  • Good detailed answer mike Commented Aug 28, 2011 at 17:08
  • Mike, thanks for your answer, these reasons would be perfectly valid. In our case the farm will contain just one type of sites with similar content, and same operational procedures, settings and policies. Hence the only requested “reason” was performance. Commented Aug 28, 2011 at 19:38

Just to add my $0.02 here and support the points above, I generally strive to create as few Web apps as possible and certainly wouldn't consider creating them for performance reasons.

Additional Web apps add additional timer jobs (around 30 per Web app!) and administrative overhead. They also necessitate extra physical entities that may not otherwise be required, such as extra IIS sites and content databases. As you point out in your question, it would be difficult if not impossible to retain a consistent URL namespace if using multiple Web applications.

On the other hand, the scenarios that Mike describes are valid reasons for considering multiple Web apps so it really depends on your requirements.

In case it helps, I wrote a blog post on this a while ago: Web [Application] limits in SP2010 - keep it low!. Feel free to check it out and let me know if it's of any use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.