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.