Software boundaries and limits for SharePoint 2013

APPLIES TO: 2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

This article describes software boundaries and limits of SharePoint Server 2013, which include:

• Boundaries: Static limits that can't 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

Learn about SharePoint limits in Microsoft 365.

Overview of boundaries and limits

This article contains information to help you understand the tested performance and capacity limits of SharePoint Server 2013, and offers guidelines for how limits relate to acceptable performance. Use the information in this article to determine whether your planned deployment falls within acceptable performance and capacity limits, and to appropriately configure limits in your environment.

The test results and guidelines provided in this article apply to a single SharePoint Server 2013 farm. Adding servers to the installation might not increase the capacity limits of the objects that are listed in the tables in the Limits and boundaries section later in this article. On the other hand, adding server computers increases the throughput of a server farm, which might be necessary to achieve acceptable performance with many objects. In some cases, the requirements for high numbers of objects in a solution might require more servers in the farm.

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 don't exist in your environment, and therefore don't apply to your solution. Only thorough testing can give you exact data related to your own environment.

Boundaries, thresholds, and supported limits

In SharePoint Server 2013, there are certain limits that are by design and can't be exceeded. Some other limits are set to default values that may be changed by the farm administrator. There are also certain limits that aren't represented by a configurable value, such as the number of site collections per web application.

• Boundaries are absolute limits that can't be exceeded by design. It's important to understand these limits to ensure that you don't make incorrect assumptions when you design your farm.

  An example of a boundary is the 2-GB document size limit; you can't configure SharePoint Server 2013 to store documents that are larger than 2 GB. This boundary is a built-in absolute value, and can't be exceeded by design.

• A threshold is a parameter that has a default value that can't be exceeded unless the value is modified. Thresholds can, in certain circumstances, be exceeded to accommodate variances in your farm design. However, it's important to understand that exceeding threshold might affect the performance of the farm in addition to the effective value of other limits.

  The default value of certain thresholds can only be exceeded up to an absolute maximum value. A good example is the document size limit. By default, the default document size threshold is set to 250 MB, but can be changed to support the maximum boundary of 2 GB.

• Supported limits define the tested value for a given parameter. The default values for these limits were defined by testing, and represent the known limitations of the product. Exceeding supported limits may cause unexpected results, significant decrease in performance, or other harmful effects.

  Some supported limits are configurable parameters that are set by default to the recommended value, while other supported limits relate to parameters that aren't represented by a configurable value.

An example of a supported limit is the number of site collections per farm. The supported limit is the largest number of site collections per web application that met performance benchmarks during testing.

It's important to know that many of the limit values that are provided in this document represent a point in a curve that describes an increasing resource load and concomitant decrease in performance as the value increases. Therefore, exceeding certain limits, such as the number of site collections per web application, may only result in a fractional decrease in farm performance. However, in most cases, operating at or near an established limit isn't a best practice, as acceptable performance and reliability targets are best achieved when a farm's design provides for a reasonable balance of limits values.

Thresholds and supported limits guidelines are determined by performance. In other words, you can exceed the default values of the limits, but as you increase the limit value, farm performance and the effective value of other limits may be affected. Many limits in SharePoint Server 2013 can be changed, but it's important to understand how changing a given limit affects other parts of the farm.

How limits are established

In SharePoint Server 2013, thresholds and supported limits are established through testing and observation of farm behavior under increasing loads up to the point where farm services and operations reach their effective operational limits. Some farm services and components can support a higher load than others so that in some cases you must assign a limit value based on an average of several factors.

For example, observations of farm behavior under load when site collections are added indicate that certain features exhibit unacceptably high latency while other features are still operating within acceptable parameters. Therefore, the maximum value assigned to the number of site collections isn't absolute, but is calculated based on an expected set of usage characteristics in which overall farm performance would be acceptable at the given limit under most circumstances.

Obviously, if some services are operating under parameters that are higher than those parameters used for limits testing, the maximum effective limits of other services will be reduced. It's therefore important to execute rigorous capacity management and scale testing exercises for specific deployments in order to establish effective limits for that environment.

Note: We don't describe the hardware that was used to validate the limits in this document, because the limits were collected from multiple farms and environments.

The Pie Metaphor

In order to understand the relationship between hardware resources, load, and performance, it's important to have a way to visualize the factors involved and how they affect each other.

Consider the capacity of a farm as a pie, the size of which represents the aggregate of factors such as servers, hardware resources such as CPUs and RAM, storage capacity, disk IOPS, network bandwidth, and latency. The size of the pie is therefore related to the overall resources of the farm; adding resources (such as farm servers) increases the size of the pie.

This pie is divided into slices that represent load from various sources: user requests, search queries, operations against installed features, timer jobs, and operating system overhead. Each of these sections must share available farm resources. If the size of one slice increases, the size of others must decrease proportionally. Since load on a farm isn't static (user requests, for example, might only be significant during certain hours of the day), the relative size of the slices is constantly in flux. However, each slice must maintain a required minimum size to operate normally, and since the functions represented by each slice are interdependent, increasing the size of one slice may place more load on other slices in addition to reducing the resources available for them to consume.

Using this metaphor, the goal of the farm's design is to make the pie large enough to accommodate the required size of each pie slice under peak load.

Now, consider a scenario where user requests increase by 100% over baseline. Let's say that about half of the requests are search queries, and the other half editing lists and documents. This increased load squeezes the other pie slices, but some farm features must also work harder to compensate. The Search service has to process more queries, most of which are handled by the cache, but some queries are passed on to the database servers, increasing their load as well. If load on the database servers becomes too great, disk queue lengths increase, which in turn increases the latency of all other requests.

Limits and boundaries

This section lists the objects that can be a part of a solution and provides guidelines for acceptable performance for each kind of object. Acceptable performance means that the system as tested can support that number of objects, but that the number can't be exceeded without some decrease in performance or a reduction in the value of related limits. Objects are listed both by scope and by feature. Limits data is provided, together with notes that describe the conditions under which the limit is obtained and 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 your deployment.

• Redesign or partition the solution to ensure that you don't exceed capacity guidelines.

Limits by hierarchy

This section provides limits sorted by the logical hierarchy of a SharePoint Server 2013 farm.

Web application limits

The following table lists the recommended guidelines for web applications.

Web server and application server limits

The following table lists the recommended guidelines for web servers on the farm.

Content database limits

The following table lists the recommended guidelines for content databases.

Site collection limits

The following table lists the recommended guidelines for site collections.

List and library limits

The following table lists the recommended guidelines for lists and libraries. For more information, see Designing large Lists and maximizing list performance (SharePoint Server 2010).