Plan for software boundaries (Office SharePoint Server)

Updated: August 30, 2010

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.


Topic Last Modified: 2016-11-14

In this article:

This article provides information to help you understand the tested performance and capacity limits of Microsoft Office SharePoint Server 2007, provides information about the test environment and test results, and offers guidelines for acceptable performance. Use the information in this article to determine whether your planned deployment falls within acceptable performance and capacity limits.

Some of the guidance in this article has been updated for Office SharePoint Server 2007 with SP1. For a comprehensive list of Office SharePoint Server 2007 with SP1 updates, see Downloadable book: Planning and deploying Service Pack 1 for Office SharePoint Server 2007 in a multi-server environment.

The test results and guidelines provided in this article apply to a single installation of Office SharePoint Server 2007. Adding server computers to the installation does not increase the capacity limits of the site objects that are listed in the tables in the Guidelines for acceptable performance section. On the other hand, adding server computers does increase the throughput of a server farm, which might be necessary to achieve acceptable performance with large numbers of objects. In some cases, the requirements for high numbers of objects within a solution might require the use of more than one server farm.

In this article, the guidelines are determined by performance. In other words, you can exceed the guidelines provided, but as you increase the scale, you might experience reduced performance.

Note that there are many factors that can affect performance in a given environment, and each of these factors can affect performance in different areas. Some of the test results and recommendations in this article might be related to features or user operations that do not exist in your environment, and therefore do not apply to your solution. Only thorough testing can provide you with exact data related to your own environment.

See the section Additional performance and capacity planning factors (Office SharePoint Server) in this guide for more information on other factors that can affect performance and capacity but were not part of the testing process for this guide.

This section provides the most up-to-date planning and performance guidance. The following recommendations are excerpted from the following white paper: Performance recommendations for storage planning and monitoring (

For more information about updated planning and performance guidelines for Office SharePoint Server 2007 with SP1, see Downloadable book: Planning and deploying Service Pack 1 for Office SharePoint Server 2007 in a multi-server environment.

Plan for database sizing that will enhance manageability and performance of your environment.

  • In most circumstances, to enhance the performance of Office SharePoint Server 2007, we discourage the use of content databases larger than 100 GB. If your design requires a database larger than 100 GB, follow the guidance below:

    • Use a single site collection for the data.

    • Use a differential backup solution, such as SQL Server 2005 or Microsoft System Center Data Protection Manager, rather than the built-in backup and recovery tools.

    • Test the server running SQL Server 2005 and the I/O subsystem before moving to a solution that depends on a 100 GB content database.

  • Whenever possible, we strongly advise that you split content from a site collection that is approaching 100 GB into a new site collection in a separate content database to avoid performance or manageability issues.

  • Limit content databases that contain multiple site collections to approximately 100 GB.

The limits we recommend apply only to a server running SQL Server 2005 hosting Office SharePoint Server 2007, and are not general guidance for SQL Server 2005.

If you plan to use versioning or Recycle Bins in a site, be aware of the potential impact to the site quota.

  • In libraries that have versioning enabled, the storage used for previous versions counts towards the site quota. Be aware of this fact and plan accordingly.

  • For any site, you can enable one or two Recycle Bin stages. The first stage (user and site Recycle Bins) counts toward the site quota. The second stage (the site collection Recycle Bin) does not count toward the site quota. However, the content in the second-stage Recycle Bin is added to the storage used by the site collection. Remember to plan sufficient additional storage space for the second-stage Recycle Bin. Pay close attention to the number of days you are retaining deleted documents in each Recycle Bin stage.

Use quota templates to manage site collections with similar characteristics. A quota template sets storage limits for site collections, and also provides e-mail alerts when specified storage sizes are reached. Any change made to a quota template affects only new sites; it will not affect previously created sites.

The following table lists the specifications of the computers in the test environment.


Role Specifications

Stand-alone computer

1 dual core Intel Xeon 2.8 gigahertz (GHz) 64-bit processor, 2 gigabytes (GB) RAM

Web server computer

2 dual core Intel Xeon 2.8 GHz 64-bit processors, 4 gigabytes (GB) RAM

Database computer running Microsoft SQL Server

4 dual core Intel Xeon 2.8 GHz 64-bit processors, 32GB RAM

Client computers

Pentium III 1.2 GHz processor, 1 GB RAM

A gigabit Ethernet network (one billion bits/sec) was used between the farm computers.

Testing was performed against the configurations listed in the following table.


Database server 1 Web server 2 Web servers 3 Web servers 4 Web servers 5 Web servers 6 Web servers 7 Web servers 8 Web servers












Environment-specific testing was also performed against several farm configurations. See the scenario articles listed in Estimate performance and capacity requirements (Office SharePoint Server) for information about environment-specific configuration testing.

The following charts, graphs and tables show how the test environment performed given a certain set of parameters, user operations, and load conditions. These tests were all conducted on an 8x1 Office SharePoint Server 2007 farm. Results provided apply to all Office SharePoint Server 2007 environments.

Additional configurations will be tested in the future. Test results will be published as they become available.

Performance metrics for different operations depend on how site collections are used. For example, a single site collection can have thousands of subsites, but user response times for operations that enumerate the container begin to increase as the number of site collections increases. Other operations that do not enumerate the container will continue to perform acceptably.

The subsites created for the tests break down as shown in the following table.


Type of subsite Percent of total

Team sites


Document workspace


Meeting workspace






User response time for certain operations increases with the number of sites in a site collection.

This graph shows the user response time when enumerating the sites in a site collection and when creating a new site as the number of existing sites increases.

Analysis graph—user response time versus # sites

Throughput, measured in RPS, decreases as the number of site collections in a farm increases.

The following figure shows the decrease in throughput when browsing to the home page of different site collections as the number of site collections in a single content database increases. Throughput decreases quickly as the total number of site collections increases from 2000 (RPS=265) to 16,000 (RPS=66), then RPS remains approximately 50 as the total number of site collections increases to 50,000.

SharePoint planning—throughput versus # sites

Throughput for certain operations decreases as the number of items in a folder increases.

The following figure shows the difference in throughput between viewing all items in a document library with and without the effective use of folders, which is critical for scaling. As shown in the graph below, throughput performance degrades as the number of documents increases when flat library storage is used. The quickest drop in throughput occurs when the total number of documents is less than 2,000, from 151 RPS (at 200 documents) to 63 RPS (at 2,000 documents). At 4,000 documents, throughput decreases to about 13 RPS, or an overall throughput decrease of over 90% from an empty library.

Graph: RPS versus number of docs in library

The following figure shows the relative performance between folder views when folders are used to store and organize documents, and an indexed view of a flat library structure. Each folder contains 500 documents created by different users. In this scenario, there is no significant throughput degradation up to 1 million documents for either scenario, provided that the number of items in the view does not exceed the performance threshold for your system. However, performance is better when folders are used.

Graph of performance and documents in a library

As the number of items in a folder increases, folder view performance will gradually degrade. Note that the above results are estimates based on our testing, and results may vary in your environment.

Capacity is directly affected by scalability. This section lists the objects that can compose a solution and provides guidelines for acceptable performance for each type of object. Limits data is provided, along with notes that describe the conditions under which the limit obtain as well as links to additional information where available. Use the guidelines in this article to review your overall solution plans.

If your solution plans exceed the recommended guidelines for one or more objects, take one or more of the following actions:

  • Evaluate the solution to ensure that compensations are made in other areas.

  • Flag these areas for testing and monitoring as you build and deploy your solution.

  • Re-design the solution to ensure that you do not exceed capacity guidelines.

The following tables list the objects by category and include recommended guidelines for acceptable performance. Acceptable performance means that the system as tested can support that number of objects, but that the number cannot be exceeded without some performance degradation. An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.

The following table lists the recommended guidelines for site objects.


Site object Guidelines for acceptable performance Notes Scope of impact when performance degrades

Site collection

50,000 per content database

Total farm throughput degrades as the number of site collections increases.


Site collection

150,000 per Web application

This limit is theoretical, and is dependent largely upon:

  • Performance of the database server on which the configuration database resides.

  • Performance of the Web servers in the farm.

  • Network bandwidth between the Web servers and the database server.

This is not a hard limit, and assumes a single database server. Your environment may not be able to host this many site collections per Web application. Distributing content databases across additional database servers can increase the effective limit of the number of site collections per Web application. You should perform testing to determine the actual effective limit in your environment.


Web site

250,000 per site collection

You can create a very large total number of Web sites by nesting the subsites. For example, 100 sites, each with 1000 subsites, is 100,000 Web sites. The maximum recommended number of sites and subsites is 125 sites with 2,000 subsites each, for a total of 250,000 sites.

Site collection


2,000 per Web site

The interface for enumerating subsites of a given Web site does not perform well as the number of subsites surpasses 2,000.

Site view


5 million per library

You can create very large document libraries by nesting folders, using standard views and site hierarchy. This value may vary depending on how documents and folders are organized, and by the type and size of documents stored.



2,000 per view

Testing indicates a reduction in performance beyond two thousand items. Using indexing on a flat folder view can improve performance.

List view

Document file size

50MB (2GB max*)

File save performance is proportional to the size of the file. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB.

Library, file save performance


2,000 per Web site

Testing indicates a reduction in list view performance beyond two thousand entries. For more information about large lists, see White paper: Working with large lists in Office SharePoint Server 2007.

List view

Field type

256 per list

This is not a hard limit, but you might experience list view performance degradation as the number of field types in a list increases.

List view


2,000 per document library

4,096 per list

This is not a hard limit, but you might experience library and list view performance degradation as the number of columns in a document library or list increases.

Library and list view

Web Part

50 per page

This figure is an estimate based on simple Web Parts. The complexity of the Web Parts dictates how many Web Parts can be used on a page before performance is affected.


Managed path

20 per Web application

20 managed paths is a soft limit. Managed paths are cached on the Web server, and CPU resources are used to process incoming requests against the managed path list. You should test for performance before exceeding 20 managed paths in a single Web application.

Web application

Security scope

1,000 per list

The maximum number of unique security scopes set for a list should not exceed 1,000.

A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to Office SharePoint Server. The members of an ACL for a scope can include Windows users, user accounts other than Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.


The following table lists the recommended guidelines for people objects.


People object Guidelines for acceptable performance Notes

Users in groups

2 million per Web site

You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users.

User profile

5 million per farm

This number represents the number of profiles which can be imported from a directory service, such as Active Directory, into the people profile store.

Security principal

Approximately 2,000 per ACL (Access Control List) on any securable object (scope)

The total size of the ACL on scopes can be no larger than 64kb. Because each security principal is approximately 32 bytes in size, there can be no more than approximately 2,000 security principals or less for each scope.  If this limit is reached, indexing of items in that scope, and all items below that scope, to fail.

Also, because SharePoint Groups are expanded during the indexing process, having more than 2,000 users or Directory Groups in a SharePoint group and using that group for securing scopes may cause indexing of items secured with these groups, and all items below them, to fail.

This limit only occurs when Windows Integrated Authentication is utilized.

The following table lists the recommended guidelines for search objects.


Search object Guidelines for acceptable performance Notes

Search indexes

One per SSP

Maximum of 20 per farm

Office SharePoint Server 2007 supports one content index per SSP. Given that we recommend a maximum of 20 SSPs per farm, a maximum of 20 content indexes is supported.

Note that an SSP can be associated with only one index server and one content index. However, an index server can be associated with multiple SSPs and have a content index for each SSP.

Indexed documents

50,000,000 per content index

Office SharePoint Server 2007 supports 50 million documents per index server. This could be divided up into multiple content indexes based on the number of SSPs associated with an index server.

Content sources

500 per SSP*

This is a hard limit enforced by the system.

Start Addresses

500 per content source*

This is a hard limit enforced by the system.


1,000,000 per SSP

This is the tested limit.


200 per site

This is a recommended limit per site. We recommend a maximum of 100 scope rules per scope.

Display groups

25 per site

These are used for a grouped display of scopes through the user interface.

Crawl rules

10,000 per SSP

We recommend a maximum 10,000 crawl rules irrespective of type.


15,000 per site

We recommend a maximum of 10 Best Bets and five synonyms per keyword.

Crawled properties

500,000 per SSP

These are properties that are discovered during a crawl.

Managed properties

100,000 per SSP

These are properties used by the search system in queries. Crawled properties are mapped to managed properties. We recommend a maximum of 100 mappings per managed property.

Authoritative pages

200 per relevance level

This is the maximum number of sites in each of the four relevance levels.

Results removal


This is the maximum recommended number of URLs that should be removed from the system in one operation.

Crawl logs


Number of individual log entries in the crawl log.

The following table lists the recommended guidelines for logical architecture objects.


Logical architecture object Guidelines for acceptable performance Notes

Shared Services Provider (SSP)

3 per farm (20 per farm maximum)



5* per farm

The number of zones defined for a farm is hard coded to 5.

Web application

99 per SSP

This limit includes the number of Web applications on child farms consuming resources on this SSP.

Internet Information Services (IIS) application pool

8 per Web server

Maximum number is determined by hardware capabilities.

Site collection

50,000 per Web application

Content database

100 per Web application

Site collection

50,000 per database

The following table lists the recommended guidelines for physical objects.


Physical object Guidelines for acceptable performance Notes

Index servers

1 per SSP*


Application servers running Excel Calculation Services

No limit


Query servers

No limit

Because 100 content databases are supported for each query server, the number of query servers required per farm is based on the number of content databases in the farm. For example, if there are 500 content databases in your farm, you will need at least 5 query servers.

Web server/database server ratio

8 Web servers per database server

The scale out factor is dependent upon the mix of operations.

Web server/domain controller ratio

3 Web servers per domain controller

Depending on how much authentication traffic is generated, your environment may support a greater number of Web servers per domain controller.

In our test environment, farm throughput reached a plateau at 5 Web servers per database server, and did not change substantially when additional Web servers were added. Although you can deploy up to 8 Web servers per database server, you may not realize substantial throughput gains after 5 Web servers. This is because as the number of Web servers making calls against a single database server increases, the database server eventually reaches 100% capacity. Results in your environment may vary according to the performance characteristics of your database server. You will need to conduct your own testing to determine the optimum number of Web servers in your farm environment.

Adding more Web servers to a farm after optimum throughput has been achieved may be desirable for other reasons—for example, if a substantial portion of Web server CPU utilization is consumed by user authentication. In such a case, you should conduct testing to determine the correct solution.

The following table provides guidelines for acceptable user response times for four types of user operations. Note that your business requirements may allow longer or shorter response times than suggested.

The testing goal was to provide sub-second response time for all end-user operations. However, this is not possible in all cases, so the guidelines in the following table were used.


Type of operation Examples Acceptable user response time

Common operation

  • Browsing to the home page

  • Browsing to a document library

<3 seconds

Uncommon operation

  • Creating a subsite

  • Creating a list

<5 seconds

Rare operation

  • Backing up a site

  • Creating a site collection

<7 seconds

Long-running operation

  • Indexing a site

Varies with operation and system configuration. All long-running operations will have either an information or status page.

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for Office SharePoint Server 2007.