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

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

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.