Software boundaries can be interpreted as operational limitations for a system. Some limits are finite, with a maximum allowed value, whereas others exceed performance or recommended limitations.
Boundaries, thresholds, and limits
To better understand these limits, consider a new car. This car might have the following:
■■ Four doors (a boundary)
■■ A maximum weight recommendation (occupants and cargo) of 1,000 pounds (a threshold)
■■ A maximum engine rotations per minute (RPM) limitation as given by the tachometer
(a limit)
The number of doors that the car possesses is a value that cannot be changed without significantly altering the car’s design. Exceeding the weight recommendation probably won’t cause the car to stop functioning, but will significantly affect both its performance and economy. Finally, exceeding the maximum RPM limitation is entirely possible, but the engine could fail and would surely not be warranted by the manufacturer.
Similar to our car analogy, SharePoint Server 2013 has three classes of software boundaries and limits: boundaries, thresholds, and supported limits.
Boundaries
A boundary is an absolute limit, meaning that the value given cannot be exceeded in the current version of SharePoint.
An example of this type of limit is the number of zones in a web application; there are always five: default, intranet, extranet, Internet, and custom.
Thresholds
A threshold has an initial value set, meaning that the value can be modified to a maximum value (boundary).
Before altering these values, consideration should be given as to whether your specific infrastructure can accommodate the increased load that might be caused by this change.
Supported limits
A supported limit for any particular configuration parameter is a set value based on testing conducted by Microsoft.
Although you can exceed supported limits, you might encounter unexpected results; these results could come in the form of diminished performance or unexpected behavior in the farm.
Boundary and limits overview
By the time SharePoint Server 2013 is released to manufacturing (RTM), it has gone through several development cycles. In addition to these development efforts, it has perhaps been vetted by Microsoft development and IT Pro teams, business users within Microsoft, Technology Adoption Program (TAP) members from larger external corporations, selected external partners, and others.
A direct result of the internal and external testing and usage studies carried out by Microsoft is the sheer amount of metrics documented in this process. Operational characteristics are gathered and compiled for each major component of a SharePoint farm, and recommendations are documented for optimal performance characteristics.
MORE INFO SOFTWARE BOUNDARIES AND LIMITS FOR SHAREPOINT 2013
Microsoft regularly updates a complete listing of the software boundaries and limits of SharePoint. The current software boundaries and limitations for SharePoint can be found on TechNet at http://technet.microsoft.com/en-us/library/cc262787.
Listed in the following sections is a subset of the recommended guidelines for major components of a SharePoint environment, along with their values and limit types. The sections shown do not include limits for SharePoint features such as Search, Managed Metadata, or
Workflow (they can, however, be found in the software boundaries and limits TechNet article).
Web application limits
These limits include the following guidelines:
■■ Web application This is a supported limit of fewer than 20 web applications per farm. Limit the number of web applications as much as possible, choosing instead to create additional host named site collections.
■■ Zone This is a boundary limit of five zones per each web application and is hardcoded into the system; the zones include default, intranet, extranet, Internet, and
custom.
■■ Managed path This is a supported limit of 20 per web application; each managed path is cached on the web server, requiring additional CPU resources to process. Although exceeding this limit is possible, the system should be tested in depth to ensure no performance degradation.
■■ Solution cache size This is a threshold limit of 300 MB per wen application. The InfoPath Forms Service keeps solutions in cache to avoid retrieving them from disk. When the cache size is exceeded, performance is degraded. This limit value can be changed using the Set-SPInfoPathFormsService PowerShell cmdlet.
Web server and application limits
These limits include the following guidelines:
■■ Application pools This is a supported limit of 10 per web server; this number is a guideline that is heavily influenced by the following:
■■ The amount of RAM available on the web servers.
■■ The usage characteristics for any given web application. A single highly active app pool can consume in excess of 10 GB of RAM.
Content database limits
These limits include the following guidelines:
■■ Number of content databases This is a supported limit of 500 per farm; exceeding this number does not tend to alter performance for end user operations on SharePoint:
■■ It does negatively affect the performance of administrative operations (such as creating a new site collection).
■■ If a large number of content databases are added to a farm, the recommendation is that PowerShell be favored over the web management interface for administering the web application.
■■ Content database size There are three supported limits:
■■ For general usage scenarios, the supported limit is 200 GB per content database, with a limit of 100 GB recommended to ensure ease of backup and restore for site collections.
■■ For all usage scenarios, the supported limit is 4 terabytes (TB) per content database, but you must be able to do the following:
■■ Provide disk subsystem performance of 0.25 IOPS per GB minimum, with a preferred value of 2 IOPS per GB for optimal performance.
■■ Have developed plans for high availability, disaster recovery, future capacity, and performance testing.
■■ For document archive scenarios (only), there is no explicit content database limit; sites in these databases must be based on the document center or records center site templates:
■■ As an average, less than 5 percent of the content in this database can be accessed and less than 1 percent modified or written.
■■ Interactive elements such as alerts, workflows, link fix-ups, or item level security should not be used (content routing workflows are the exception).
| MORE INFO E STIMATING PERFORMANCE AND CAPACITY REQUIREMENTS FOR LARGE-SCALE DOCUMENT REPOSITORIES Large document repositories, such as those found in the all usage and document archive scenarios of the preceding “Content database limits” section, should be constructed based on the guidelines found in the Estimate Performance and Capacity Requirements for Large Scale Document Repositories document at http://technet.microsoft.com/en-us/library/ ff608068.aspx. This document was written for the 2010 version of SharePoint Server, but is still quite pertinent and will most likely be updated in the near future. |
■■ Content database items This is a supported (and tested) limit of 60 million items; exceeding this limit should include multiple content databases.
■■ Site collections per content database This is a supported limit of 10,000 site collections maximum:
■■ 2,500 nonpersonal site collections and 7,500 personal site collections.
■■ 10,000 personal site collections.
■■ This limitation has to do with upgrade times; larger numbers of site collections results in more difficult upgrades.
■■ Content databases have a default warning and maximum levels of 2,000 and 5,000 sites, respectively.
■■ Setting the warning and maximum levels for the number of sites in a content database can be done via Central Administration or the Set-SPContentDatabase commandlet with the -WarningSiteCount parameter.
■■ Remote BLOB storage subsystem on Network Attached Storage (NAS) This is a boundary limit of 20 milliseconds maximum to the first byte response time from the NAS.
Site collection limits
These limits include the following guidelines:
■■ Site collections per farm This is a supported limit of 750,000 sites (500,000 personal sites and 250,000 standard sites):
■■ An excessive concentration of site collections within a single web application can place a substantial load on the memory allocated to a web server.
■■ Search crawls across a large volume of site collections can also generate excessive memory loads on a web server.
■■ As a safety measure, you should plan to configure a web application to recycle before memory on any web server falls beneath 2 GB.
■■ Web sites per site collection This is a supported limit of 250,000 per site collection and speaks directly to the amount of sites that are nested beneath other sites in a particular site collection.
■■ Site collection size This is a supported limit wherein a single site collection can utilize all the space afforded to it by the content database. As a result, the recommendation is that the content database (and by extension, the site collection) be limited to 100 GB.
■■ Number of device channels per publishing site collection This is a boundary limit of 10 device channels.
List and library limits
These limits include the following guidelines:
■■ List row size This is a boundary limit of 8,000 bytes per row; 256 bytes are reserved for built-in columns, which leaves 7,744 bytes for end-user columns. The size per type of column is discussed in the section on column limits.
■■ This limit can present itself when promoting a large amount of columns from an InfoPath form.
■■ File size This is a boundary limit of 2 GB; the default maximum file size is 50 MB but can be increased to 2 GB. Increasing file size to 2 GB can have a negative effect on farm performance.
■■ Documents This is a supported limit of 30 million documents per library; however, care should be given in advance about how documents will be presented with the use of nesting folders or views.
■■ Major versions This is a supported limit of 400,000 major versions of documents; exceeding this amount can cause issues with basic file operations (open, save, delete, version history, and so on).
■■ Minor versions This is a boundary limit of 511 minor file versions and cannot be exceeded.
■■ Items This is a supported limit of 30 million items per list; performance can be increased in large lists by way of views, and so on, although the limit can itself be affected by the following:
■■ How many columns are in the list; large numbers of columns in a large list will negatively affect performance.
■■ What the usage characteristics of the list are; large numbers of users reading and writing content to a large list will negatively affect performance.
■■ Rows size limit This is a supported limit of six table rows internal to the database used for a list or library item; so called “wide lists,” which contain a large number of columns (see list row size on the previous page) might be wrapped over several table rows in a content database.
■■ Six rows is the default size limit.
■■ To accommodate more rows, farm administrators can alter the number of rows using PowerShell and the object model method SPWebApplication.MaxListItemRowStorage.
■■ Bulk operations This is a boundary limit of 100 items per bulk operation; the user interface allows for the selection of and interaction with a maximum of 100 items in any one operation.
■■ List view lookup threshold This is a threshold limit of eight join operations per query; specifies the maximum number of joins per query (lookup, person/group, workflow status, and so on) and blocks any join requests beyond the limit.
■■ List view threshold Specifies the maximum number of items that can be processed by a user during business hours. Outside this time window, queries are unrestricted.
■■ List view threshold for users is a threshold limit of 5,000 items processed at any one time.
■■ List view threshold for auditors and administrators is a threshold limit of 20,000 items processed at any one time.
■■ Subsite This is a threshold limit of 2,000 per site view; enumerating subsites for a given site past the 2,000 limit (via the interface) does not perform well. This limitation also affects the all site content page and the tree view control.
■■ Coauthoring in Word and PowerPoint (.docx, .pptx, and .ppsx files) This is a threshold limit of 10 concurrent editors per document; it is possible to have as many as 99 coauthors for any given document (this is a hard limit), but performance will degrade after 10 coauthors are editing the document.
■■ Security scope This is a threshold limit of 1,000 per list; this is a maximum number and should not be exceeded.
MORE INFO DESIGNING LARGE LISTS AND MAXIMIZING LIST PERFORMANCE
Lists and document libraries containing a large volume of items have the same performance characteristics and supported limits. As the amount of individual items increases, performance can be adversely affected. Microsoft provides prescriptive guidance for maximizing the performance of large lists and libraries in the “Designing large lists and maximizing list performance” document that can be found at http://technet.microsoft.
com/en-us/library/cc262813. This document was written for the 2010 version of SharePoint Server but is still quite pertinent and will most likely be updated in the near future.
Page limits
These limits include the following guideline:
■■ Web parts This is a threshold limit of 25 per wiki or web part page; this limit is an estimate because the complexity of the web parts determines how many can be used on a page before performance is affected.
Security limits
These limits include the following guidelines:
■■ Number of SharePoint groups a user can belong to This is a supported limit of 5,000; this is not a hard limit, but follows the way Active Directory membership behaves. Exceeding this limit causes slower performance based on the amount of security checks required for an individual user.
■■ Users in a site collection This is a supported limit of 2 million per site collection; if this number is to be exceeded, management of the site collection should be done via PowerShell instead of the user interface.
■■ Active Directory principals/users in a SharePoint group This is a supported limit of 5,000 per SharePoint group; performance is the main consideration here because fetching user for permissions validation and rendering memberships can be adversely affected.
■■ SharePoint groups This is a supported limit of 10,000 per site collection; beyond 10,000 groups, actions such as adding a user to a group, creating a new group, and rendering group views can take more time to process.
■■ Security principal; size of the security scope This is a supported limit of 5,000 per Access Control List (ACL); every time the scope changes, there is a calculation that occurs. As the scope size increases, so does the amount of time required for the calculation.
there is a significant number of these metrics given for SharePoint 2013. It would be quite hard to memorize each limit and know whether it is a boundary, threshold, or limit (for the test); concentrate on the ones that have the largest impact—those that affect raM, storage, and processor capacity.
