In SharePoint 2013, individual services can be
configured independently and third-party companies can add services. The
services infrastructure gives you control over which services are deployed and
how services are shared.
Services that are deployed are named service
applications. A service application provides a resource that can be shared
across sites throughout a farm, and can be accessed by users through a hosting
web application. Service applications are associated to web applications by
service application connections. Some services can be shared across farms.
For more information about the logical structure
of services and service applications, see Architecture.
For more information about how to manage service
applications that included instructions for publishing service applications
across farms, see Manage service applications in SharePoint 2013 and Share
service applications across farms in SharePoint 2013.
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
is important to be aware 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 is not 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 is
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 is not 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 used
for limits testing, the maximum effective limits of other services will be
reduced. It is 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 do not 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 a variety of 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 is not 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 will increase,
which in turn increases the latency of all other requests.
