Site vs. Site Collection & Capacity Planning Revisited

I don’t know if you can summarize and resummarize and recap capacity planning content enough.  I’ve been working on the deck for the webcast this week on Admin Fundamentals and tried to roll up the entire contents of the capacity planning deck and my talking points into one chart.

Before we get into the chart we need to revisit a fundamental SharePoint term: Site

The Most Confusing thing to get over is what is a Site vs. Site Collection…
(Let me help you with the decoder ring!  Can you believe I had this discussion with a couple of MVPs this week?)


Site = Web = Spweb aka subweb

A site is a web is an SPWeb to developers, and a Subweb to old timers or subsite to those just trying to use something to distinguish it from a site collection.

STSADM a Site is a Web; in the stsadm interface you may type stsadm -o enumweb to enumerate a list of sites for a site collection

In the Site Settings UI the site is most often referred to as a site, for example the ability to create sites and workspaces would be referring to sites within the site collection.

In the Central Admin UI it would be referred to as a web.

Spweb = to a developer they would iterate through a list of spwebs for an spsite.


Site Collection = SpSite = Portal = Sometimes referred to as a Top Level Site

Really the site collection is the container for sites or webs. I won’t get into it’s special properties.

STSADM = Site stsadm -o enumsites would give you a list of site collections in a web application

Central Admin = Site Limiting the number of sites in a database is limiting the number of site collections per database

Developers Site = SPSite would be the equivalent.  The Spsite would be the container and would have spwebs on the inside.

In the end user UI, for example when configuring the ability to create sites or site collections from the site directory, but this isn’t always the case.

Containment Capacity Guidance

Unit  per Unit TechNet Max  Joel’s Guideline  Joel’s Recommended MAX 
Web Apps per Farm  8 5 Content Webapps with 8GB RAM  16 app pools – 100 web apps w/ 32GB RAM, 64 bit 
Databases per WebApp    100 per SQL server (with one SQL instance) 300 with 32GB RAM, 64 bit 
Site Collection per Web App  50000 100,0000+ (only one web app)   
Size per content database    100GB  1 TB with serious list and site optimization (advanced only) 
Size per Site Collection    15GB in multi-tenant DB 100GB in dedicated DB  25GB in multi tenant db  1TB in dedicated Db 
Sites per Site 2000 100 500
Items per list 5 million 1000 items per view with search (No Allitems) Custom Interface for anything beyond 4000 items


Tons more detail and perspective in the SharePoint Key Capacity Info

Reorganization is a popular topic these days in relation to SharePoint Optimization techniques.

Quest has recently launched a beta of a new product designed around reorganizing your data.  This tool is called the Migration Manager Reorganization Wizard.

"The Reorg Wizard beta provides essential site reorganization and restructuring tools for SharePoint 2007 administrators allowing them to:

·         Move SharePoint sites within the same SharePoint 2007 server farm

·         Promote parts of a site tree to a new site collection on the same or different web application

·         Optimize SharePoint database storage by moving site collections between content databases

·         Perform cascaded site deletes to finalize the site move or roll back a failed operation"

I plan to get a demo of this tool and evaluate it and provide feedback here.

I like to think about SharePoint as a tree and see this process as a pruning process where the Tree itself is not structurally sound if it gets too tall (long urls) or too thick and stunting growth (too much in one database).

You’ll have to let me know what you think.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.