Limits and boundaries
The
below table gives a detailed information on the guidelines for acceptable
performance for objects in SharePoint. In this section I am focusing on
the Web applications, Web
server and application servers, Content databases and Site collections. Acceptable
performance means that the system as tested can support that number of objects,
but that the number cannot be exceeded without some decrease in performance or
a reduction in the value of related limits.
• Boundaries: Static limits that cannot be exceeded by design
• Thresholds: Configurable limits that can be exceeded to accommodate specific requirements
• Supported limits: Configurable limits that have been set by default to a tested value
Limits by hierarchy
This section
provides limits sorted by the logical hierarchy of a SharePoint Server 2010
farm.
Web application limits
The following table lists the recommended guidelines for Web applications.
Limit
|
Maximum value
|
Limit type
|
Notes
|
Content database
|
300 per Web application
|
Supported
|
With 300 content databases per Web
application, end user operations such as opening the site or site collections
are not affected. But administrative operations such as creating a new site
collection will experience decrease in performance. We recommend that you use
Windows PowerShell to manage the Web application when a large number of
content databases are present, because the management interface becomes slow
and difficult to navigate.
|
Zone
|
5 per Web application
|
Boundary
|
The number of zones defined for a
farm is hard-coded to 5. Zones include Default, Intranet, Extranet, Internet,
and custom.
|
Managed path
|
20 per Web application
|
Supported
|
Managed paths are cached on the
Web server, and CPU resources are used to process incoming requests against
the managed path list.
Exceeding 20 managed paths per Web
application adds more load to the Web server for each request.
If you plan to exceed twenty
managed paths in a given Web application, we recommend that you test for
acceptable system performance.
|
Solution cache size
|
300 MB per Web application
|
Threshold
|
The solution cache allows the
InfoPath Forms service to hold solutions in cache in order to speed up
retrieval of the solutions. If the cache size is exceeded, solutions are
retrieved from disk, which may slow down response times. You can configure
the size of the solution cache by using the Windows PowerShell cmdlet
Set-SPInfoPathFormsService.
|
Site collection
|
250,000 per Web application
|
Supported
|
The maximum recommended number of
site collections per Web application is 250,000.
Note that this limit is affected
by other factors that might reduce the effective number of site collections
that can be supported by a given Web application. Care must be exercised to
avoid exceeding supported limits when a container object, such as a content
database, contains a large number of other objects.
For example, in a farm that
contains a large number of Web applications, the total number of site
collections might reach a number that cannot effectively be supported by farm
resources. This can be true even when both the number of Web applications per
farm and the number of site collections per Web application fall within their
supported limits.
Similarly, if a farm contains a
smaller total number of content databases, each of which contains a large
number of site collections, farm performance might be adversely affected long
before the supported limit for the number of site collections is reached.
The following case illustrates
this point.
Farm A contains a Web application
that has 200 content databases, a supported configuration. If each of these
content databases contains 200 site collections, the total number of site
collections in the Web application will be 40,000, which falls within
supported limits. However, if each content database contains 2,000 site
collections, even though this number is supported for a content database, the
total number of site collections in the Web application will be 400,000,
which exceeds the limit for the number of site collections per Web
application.
|
Web server and application server limits
The following
table lists the recommended guidelines for Web servers on the farm.
Limit
|
Maximum value
|
Limit type
|
Notes
|
Application pools
|
10 per Web server
|
Supported
|
The maximum number is determined
by hardware capabilities.
This limit is dependent largely
upon:
·
The
amount of RAM allocated to the Web servers
·
The
workload that the farm is serving, that is, the user base and the usage
characteristics (a single highly active application pools can reach 10 GB or
more)
|
Content database limits
The following
table lists the recommended guidelines for content databases.
Limit
|
Maximum value
|
Limit type
|
Notes
|
Content database size (general
usage scenarios)
|
200 GB per content database
|
Supported
|
We strongly recommended limiting
the size of content databases to 200 GB, except when the circumstances in the
following rows in this table apply.
If you are using Remote BLOB
Storage (RBS), the total volume of remote BLOB storage and metadata in the
content database must not exceed this limit.
|
Content database size (all usage
scenarios)
|
4 TB per content database
|
Supported
|
Content databases of up to 4 TB
are supported when the following requirements are met:
·
Disk
sub-system performance of 0.25 IOPs per GB. 2 IIOPs per GB is recommended for
optimal performance.
·
You
must have developed plans for high availability, disaster recovery, future
capacity, and performance testing.
You should also carefully consider
the following factors:
·
Requirements
for backup and restore may not be met by the native SharePoint Server 2010
backup for content databases larger than 200 GB. It is recommended to
evaluate and test SharePoint Server 2010 backup and alternative backup
solutions to determine the best solution for your specific environment.
·
It
is strongly recommended to have proactive skilled administrator management of
the SharePoint Server 2010 and SQL Server installations.
·
The
complexity of customizations and configurations on SharePoint Server 2010 may
necessitate refactoring (or splitting) of data into multiple content
databases. Seek advice from a skilled professional architect and perform
testing to determine the optimum content database size for your
implementation. Examples of complexity may include custom code deployments,
use of more than 20 columns in property promotion, or features listed as not
to be used in the over 4 TB section below.
·
Refactoring
of site collections allows for scale out of a SharePoint Server 2010 implementation
across multiple content databases. This permits SharePoint Server 2010
implementations to scale indefinitely. This refactoring will be easier and
faster when content databases are less than 200 GB.
It is suggested that for ease of
backup and restore that individual site collections within a content database
be limited to 100 GB.
|
Content database size (document
archive scenario)
|
No explicit content database limit
|
Supported
|
Content databases with no explicit
size limit for use in document archive scenarios are supported when the
following requirements are met:
·
You
must meet all requirements from the “Content database size (all usage
scenarios)” limit earlier in this table, and you should ensure that you have
carefully considered all the factors discussed in the Notes field of that
limit.
·
SharePoint
Server 2010 sites must be based on Document Center or Records Center
site templates.
·
Less
than 5% of the content in the content database is accessed each month on
average, and less than 1% of content is modified or written each month on
average.
·
Do
not use alerts, workflows, link fix-ups, or item level security on any
SharePoint Server 2010 objects in the content database.
|
Content database items
|
60 million items including
documents and list items
|
Supported
|
The largest number of items per
content database that has been tested on SharePoint Server 2010 is 60 million
items, including documents and list items. If you plan to store more than 60
million items in SharePoint Server 2010, you must deploy multiple content
databases.
|
Site collections per content
database
|
2,000 recommended
5,000 maximum
|
Supported
|
We strongly recommended limiting
the number of site collections in a content database to 2,000. However, up to
5,000 site collections in a database are supported.
These limits relate to speed of
upgrade. The larger the number of site collections in a database, the slower
the upgrade.
The limit on the number of site
collections in a database is subordinate to the limit on the size of a
content database that has more than one site collection (200 GB). Therefore,
as the number of site collections in a database increases, the average size
of the site collections it contains must decrease.
Exceeding the 2,000 site
collection limit puts you at risk of longer downtimes during upgrades. If you
plan to exceed 2,000 site collections, we recommend that you have a clear
upgrade strategy, and obtain additional hardware to speed up upgrades and
software updates that affect databases.
To set the warning level for the
number of sites in a content database, use the Windows PowerShell cmdlet
Set-SPContentDatabase with the -WarningSiteCount parameter.
|
Remote BLOB Storage (RBS) storage
subsystem on Network Attached Storage (NAS)
|
Time to first byte of any response
from the NAS cannot exceed 20 milliseconds
|
Boundary
|
When SharePoint Server 2010 is
configured to use RBS, and the BLOBs reside on NAS storage, consider the
following boundary.
From the time that SharePoint
Server 2010 requests a BLOB, until it receives the first byte from the NAS,
no more than 20 milliseconds can pass.
|
Site collection limits
The following table lists the recommended guidelines for
site collections.
Posts
Thanks for taking time and sharing your feedback John :-)
ReplyDelete