Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Number of site collections

  Asked By: Nicole    Date: May 17    Category: Sharepoint    Views: 1327

we are building an app in SP where each customer needs their own site
and a few subsites. There will be about 8000 needed initially. We are using a
site collection for each customer for the segmentation benefits, and even more
so because there is a documented 2000 site limit per site collection (since
that's not enough, we'd have to segment the customers' sites into different,
arbitrary site collections. Given this fact, it seems we may as well use a site
collection for each customer). The documented limit is 15k site collections per

Is there significantly more overhead for a site vs. a site collection?

Also, we need to roll up data from across them all into several different web
parts per page. To make this not slow, we are querying the MOSS search index
for this. It seems to be working ok (except the first time a rollup page is
loaded before caching, it takes 25+ seconds to load).

Does anyone see any inherit problems with this approach? For performance? The
database memory usage does spike, but I am assuming SQL Server can handle it.



4 Answers Found

Answer #1    Answered By: Latanya Nieves     Answered On: May 17

The recommended limit is 2000 subsites  for a single site, not the whole
collection. By nesting you can have up to 250,000 sites in a collection. As far
as site  Collections for a database, that's more a matter of recovery time than
anything else as the only way to control the size of the database is by placing
different collections  in different databases to manage size. All of the content
for a single Site Collection must be in a single database and cannot be stripped
across multiple databases.

As for site vs site collection, this is a management issue. The Site Collection
is the administrative boundary of SharePoint. Users, Content types, Master
Pages, Columns, etc, do not span the Site Collection border and must be
maintained for each collection. If you are using common functions across
multiple site collections, it can become a real headache to manage to many
Collections as opposed to fewer collections with more sub-sites.

I would think that if you took a look at your customers, you could certainly
find a means of grouping them into one category or another to make management

Answer #2    Answered By: Vidisha Pathak     Answered On: May 17

What scares me, whether having sites or site
collections, is just having that many (8k), and having it still perform well. I
will see!

Answer #3    Answered By: Malcolm Maxwell     Answered On: May 17

Whether you have 8000 people hitting a single site  collection, or 8000 site
collections, each with 1 person hitting it, is not going to make that much
difference on your performance. The issue is how do you break up all that data
and how do you manage all of that content. 8000 Site collections  is much more of
an administrative nightmare than trying to manage a single Site collection of
8000 sites. On the other hand, trying to back-up and restore a single Site
Collection containing all that content is far more of a problem than backing up
multiple, smaller collections. You have to look at the security needs,
back-up/restore, management processes of the content, not how many users are
going to hit it.

Now, one more thing to remember, not ever site collection needs to be in its own
web application. Now that WOULD cause a performance issue.

Answer #4    Answered By: Mayur Mandal     Answered On: May 17

On that note, another practical thing to consider, I am assuming you have these
on a single web application...I would be interested to see how the MOSS Central
Admin site  collection listing and selection controls work with 8,000 items. They
are not the most useful controls when there is a lot of data to look at.

How were you breaking out the content DB's? You need to have them broken out in
a healthy manner but if you took it to 1 extreme and had 8,000 DBs your SQL
management tools would get loaded up pretty good.

I am with Daniel, make sure you completely understand the maintenance of these
and if you can group your clients into region, vertical, product class, etc and
cut down on 8,000 site collections  that would be nice. If you already have need
to rollups that cover all site collections, I would be concerned sooner or later
there would be something called for that would need this cabaility and not be
able to utilize the search data. I would have to think cycling through 8,000
SPSite objects (in a code behind) would be a resource intensive bit of coding.

Crazy....probably not. I have had situations that called for large site
collection counts (not 8,000 but in the 1,000's). The maintenance was always the

Didn't find what you were looking for? Find more on Number of site collections Or get search suggestion and latest updates.