适用于：
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
本文概述了如何有效地规划和管理 SharePoint Server 2013 环境的容量。 本文还介绍了如何通过对性能和批量数据的分析充分了解部署的容量需求和功能。 它还讨论了影响容量的主要应用程序影响，包括内容特征和用途。
重要
[!重要说明] 本文中的某些值是基于测试结果和与 SharePoint 2010 产品相关的其他信息，并不代表 SharePoint Server 2013 的最终值。 本文在 SharePoint Server 2013 相关数据可用后会采用正确的值、相关内容的链接和其他信息进行更新，然后再重新发布。
由于任何实现的内容和用途都不会静止不变，因此容量管理 是一个持续的过程。 用户需要针对增长和变化进行规划，以便基于 SharePoint Server 2013 的环境可以持续提供有效的业务解决方案。
容量规划 只是容量管理周期的一部分。 它是最初的一组活动，这组活动使得设计架构师坚信有一个初始体系结构最适合 SharePoint Server 2013 部署。 容量管理模型还包括可帮助您验证和优化初始体系结构的其他步骤，并提供一个反馈循环，可用于重新规划和优化生产环境，直到该环境可以通过所选的最佳硬件、拓扑和配置满足设计目标。
术语表
SharePoint Server 2013 容量管理文档中使用了以下专业术语。
RPS 每秒请求数。 服务器场或服务器每秒接收的请求数。 这是测量服务器和服务器场负载的常用方法。 服务器场处理的请求数大于页面加载和最终用户交互数。 这是因为每个页面包含若干个组件，而加载页面时每个组件又会创建一个或多个请求。 有些请求的事务成本低于其他请求。 在实验室测试和案例研究文档中，由于有些请求和响应对服务器场资源的影响很小，因此我们从用于计算 RPS 的请求中删除了 401 个请求和响应（身份验证握手）。
高峰期 服务器场中的负载在一天内处于最大值的时间。
高峰负载 服务器场中的平均最大每日负载，以 RPS 度量。
瞬时负载峰值 在通常高峰期之外的瞬态负载峰值。 用户流量意外增加、由于管理操作导致服务器场吞吐量减少或者此类因素组合，均可能引起瞬时负载峰值。
向上扩展 向上扩展是指向服务器中添加处理器或内存等资源。
向外扩展 向外扩展是指向服务器场中添加更多服务器。
应阅读容量管理文章的人员
在决定是否应阅读此内容时，请考虑以下问题。
评估 SharePoint Server 2013
重要
本节中的某些链接适用于 SharePoint Server 2010 及其他早期的产品版本，这些链接将在此内容的 SharePoint Server 2013 版本推出后得到更新。
我是一名 IT 专业人员或业务决策制定者，我正在寻找一个适用于特定业务问题的解决方案。 SharePoint Server 2013 是我的部署选项。 它能否提供可以满足我的特定要求的功能和可伸缩性？
有关 SharePoint Server 2013 如何缩放以满足特定解决方案的需求以及如何确定支持自己要求的所需硬件的信息，请参阅下文中的以下各节：
有关如何评估 SharePoint Server 2013 以满足特定业务要求的信息，请参阅以下文章：
从 Office SharePoint Server 2010 升级
我当前使用的是 SharePoint Server 2010。 SharePoint Server 2013 中有哪些更改，升级时需要考虑什么？ 升级会对拓扑的性能和规模产生什么影响？
有关更多常规升级考虑事项以及如何规划和执行从 Office SharePoint Server 2007 升级的指导，请参阅以下文章：
调整和优化基于 SharePoint 的实时环境
我已部署 SharePoint Server 2013，我想确保已准备好适当的硬件和拓扑。 我应如何正确验证和维护我的体系结构？
有关 SharePoint Server 2013 场的监视和性能计数器的信息，请参阅以下文章：
有关如何使用内置到中央管理界面的运行状况监视工具的信息，请参阅以下文章：
我已部署 SharePoint Server 2013，但遇到性能问题。 我应如何排查并优化我的环境？
有关 SharePoint Server 2013 场的监视和性能计数器的信息，请参阅以下文章：
有关用于优化 SharePoint Server 2013 场的工具和技术的信息，请参阅以下文章：
有关通过使用内置到中央管理界面的运行状况监视工具进行疑难解答的信息，请参阅以下文章：
有关特定 SharePoint Server 2010 服务和功能可用的容量管理文章的列表（更多文章将在发布后添加），请参阅以下文章：
有关数据库大小调整和性能的信息，请参阅以下文章：
有关远程 BLOB 存储 (RBS) 的信息，请参阅以下文章：
开头到结尾
我想了解有关 SharePoint Server 2013 容量管理的所有内容。 我应从哪里开始？
有关容量管理的常规概念及其他文档和资源的链接的信息，请参阅以下文章：
有关容量管理的其他信息，请参阅此概述文章的其他随附文章：
你现在应该已经很好地了解了概念。 有关 SharePoint Server 2013 限制和边界的信息，请参阅以下文章：
准备好识别基于 SharePoint Server 2013 的环境的起点拓扑后，您可以查找可用技术案例研究库，查找最符合您需求的案例研究。 有关 SharePoint Server 2010 案例研究的列表（SharePoint Server 2013 案例研究将在可用后发布），请参阅以下文章：
- Performance and capacity technical case studies (SharePoint Server 2010)（性能和容量技术案例研究 (SharePoint Server 2010)）
有关通过使用内置到中央管理界面的运行状况监视工具进行运行状况监视和疑难解答的信息，请参阅以下文章：
有关如何虚拟化基于 SharePoint Server 2013 的服务器的详细信息，请参阅以下文章：
有关高可用性和灾难恢复的详细信息，请参阅以下文章：
性能的四个基本要素
在确定解决方案的规模时，容量管理关注以下四个主要方面：
延迟 在容量管理中，延迟被定义为在用户启动操作（如单击超链接）与将最后一个字节传送给客户端应用程序或 Web 浏览器之间的持续时间。
吞吐量 吞吐量定义为服务器或服务器场可以处理的并发请求数。
数据规模 数据规模定义为系统可以托管的内容大小和数据集。 内容数据库的结构和分布对于系统处理请求的时间（延迟）和系统可以处理的并发请求数（吞吐量）有显著影响。
可靠性 可靠性用于衡量系统在一段时间内满足所设定的延迟和吞吐量目标的能力。
管理环境容量的主要目标是建立并维护一个系统，以满足组织的延迟、吞吐量、数据规模和可靠性目标。
延迟
延迟，也称为最终用户感知的延迟，它主要包含三个部分：
服务器接收和处理请求所用的时间。
通过网络传输请求和服务器响应所用的时间。
在客户端应用程序中显示响应所用的时间。
不同的组织会根据业务要求和用户预期定义不同的延迟目标。 有些组织可以承受几秒的延迟，而其他组织则需要事务处理速度非常快。 为实现快速事务进行优化通常成本较高，并且需要客户端和服务器功能更为强大、使用更新的浏览器和客户端应用程序版本、高带宽网络解决方案，可能还要进行开发投资和页面优化。
以下列表介绍了导致最终用户感知的延迟更长的一些主要因素和一些常见问题的示例。 在客户端的地理位置远离服务器场或通过低带宽网络连接访问服务器场的情况下，这些因素的影响尤其明显。
未优化的功能、服务或配置参数可能会耽搁请求的处理，并影响远程和本地客户端的延迟。 有关详细信息，请参阅下文中的Capacity management and sizing overview for SharePoint Server 2013和Capacity management and sizing overview for SharePoint Server 2013。
有些网页会对服务器生成不必要的请求来下载所需的数据和资源。 优化将包括下载最少数量的资源来提取页面、减小图像大小、在允许匿名访问的文件夹中存储静态资源、在从服务器中异步下载资源的同时群集请求并启用页面交互。 这些优化对于获得可接受的初次访问浏览体验非常重要。
通过网络传输大量数据会增加延迟并降低吞吐量。 例如，页面中的图像和其他二进制对象应尽可能使用压缩格式（如 .png 或 .jpg）而不是位图。
未针对二次访问页面加载进行优化的网页。 由于有些页面资源缓存在客户端上，而浏览器只需下载未缓存的动态内容，因此二次访问页面加载的页面加载时间 (PLT) 会得到改进。 不可接受的二次访问页面加载延迟通常是由二进制大型对象 (BLOB) 缓存配置不正确或客户端计算机中禁用本地浏览器缓存引起的。 优化将包括在客户端中正确缓存资源。
包含未优化的自定义 JavaScript 代码的网页。 这可能会使在客户端中呈现页面的过程变慢。 优化将延迟客户端对 JavaScript 的处理，直到其余页面已加载完成，并首选调用脚本而不是添加内联的 JavaScript。
吞吐量
吞吐量 由服务器场在单位时间内可以处理的请求数来描述，通常用于根据组织的规模及其使用特征来衡量系统预计可以维持的操作的规模。 每个操作都具有由服务器场资源引发的特定成本。 了解需求并部署可始终满足需求的服务器场体系结构需要估计预期负载，并在负载条件下测试体系结构，以验证在并发程度很高、系统压力较大时延迟不会降到目标值以下。
低吞吐量情况的一些常见示例包括：
硬件资源不足 当服务器场收到的请求多于它可以并发处理的请求时，有些请求会排入队列，这样累积的结果就是推迟每个后续请求的处理，直到需求减少到可以清除队列为止。 优化服务器场以维持较高吞吐量的一些示例包括：
确保场服务器中的处理器未过度利用。 例如，如果高峰期或瞬时负载峰值期间的 CPU 使用率持续超过 80%，则可添加更多服务器或将服务重新分配给其他场服务器。
确保应用程序服务器和 Web 服务器上有足够内存来包含完整缓存。 这有助于避免调用数据库，以便为针对未缓存内容的请求提供服务。
确保数据库服务器没有瓶颈。 如果总可用磁盘 IOPS 不足以支持高峰需求，则添加更多磁盘或将数据库重新分配给利用率低下的磁盘。 有关详细信息，请参阅监视和维护 SharePoint Server 2013 的"消除瓶颈"一节。
如果向现有计算机中添加资源仍无法解决吞吐量问题，则可添加服务器并将受影响的功能和服务重新分配给新服务器。
未经优化的自定义网页 在生产环境中向常用页面添加自定义代码通常会引起吞吐量问题。 添加自定义代码可能会生成到数据库服务器的其他往返行程或服务于数据请求的 Web 服务。 自定义不常使用的页面可能不会显著影响吞吐量，但如果每天请求上千次，即使进行良好优化的代码也会降低服务器场的吞吐量。 SharePoint Server 2013 管理员可以使开发人员仪表板能够识别需要优化的自定义代码。 下面是优化自定义代码的一些示例：
最大限度地减少 Web 服务请求和 SQL 查询的数量。
在前往数据库服务器的每个行程中提取所需的最少数据，同时最大限度地减少所需往返行程数。
避免向常用页面中添加自定义代码。
在检索经筛选的数据量时使用索引。
不受信任的解决方案 在 bin 文件夹中部署自定义代码会导致服务器性能变慢。 每次请求包含不受信任代码的页面时，SharePoint Server 2013 都必须先执行安全检查，然后才能加载页面。 除非有特殊原因需要部署不受信任的代码，否则应在 GAC 中安装自定义程序集，以避免不必要的安全检查。
数据规模
数据规模 是服务器或服务器场在满足延迟和吞吐量目标的同时可以存储的数据量。 通常，服务器场中的数据量越大，对总体吞吐量和用户体验的影响越大。 用于跨磁盘和数据库服务器分布数据的方法也会影响服务器场延迟和吞吐量。
数据库大小、数据体系结构和足够的数据库服务器硬件对于最佳数据库解决方案都至关重要。 在理想部署中，根据限制指导确定内容数据库大小并跨物理磁盘分布这些数据库，以便不会因磁盘过度利用而对请求进行排队，并且数据库服务器能够支持高峰负载和意外的瞬时峰值，而不会超出资源利用阈值。
此外，有些操作会在操作期间锁定某些表。 大型网站删除就是此情形的一个示例，该操作会在删除操作完成之前，锁定网站所在内容数据库中的相关表。
以下是针对数据和存储性能优化服务器场的示例：
确保数据库正确分布在数据库服务器上，并且数据库服务器资源足以支持数据的数量和分布。
将数据库卷分隔为由唯一的物理磁盘主轴构成的唯一逻辑单元 (LUN)。 使用具有短寻道时间和适当 RAID 配置的多个磁盘来满足数据库服务器的存储需求。
如果数据集包含许多二进制大型对象 (BLOB)，则可使用远程 BLOB 存储 (RBS)。 RBS 可提供以下好处：
BLOB 数据可以存储在配置用于处理简单存储的较为便宜的存储设备上。
对 BLOB 存储的管理由专门设计用于处理 BLOB 数据的系统进行控制。
数据库服务器资源可释放用于数据库操作。
这些好处并不是免费的。 在用 SharePoint Server 2013 实现 RBS 之前，您应评估这些潜在好处是否会抵消实现和维护 RBS 的成本和限制。
有关如何规划数据规模的详细信息，请参阅存储和 SQL Server 容量规划与配置 (SharePoint Server)。
可靠性
可靠性 是对服务器场在一段时间内满足设定的延迟、吞吐量和数据容量目标的能力的综合度量。 对于可靠的服务器场而言，正常运行时间、响应速度、失败率以及延迟瞬时峰值的频率和幅值都在设定的目标和操作要求内。 可靠的服务器场在高峰负载和高峰期内或执行系统操作（如爬网或日常备份）时也能继续维持延迟和吞吐量目标。
维持可靠性的一个主要因素是常见管理操作对性能目标的影响。 在某些操作（如重新生成数据库索引、维护计时器作业或删除包含大量内容的多个网站）期间，系统可能无法快速处理用户请求。 在此情况下，最终用户请求的延迟和吞吐量都会受到影响。 对服务器场的影响取决于此类不常见操作的频率和事务成本以及它们是否在正常工作时间运行。
有关如何维持更可靠系统的一些示例包括：
在非高峰期计划资源密集型计时器作业和管理任务。
在现有场服务器中向上扩展硬件，或通过添加 Web 服务器、应用程序服务器或其他数据库服务器进行向外扩展。
将资源密集型服务和功能分配给专用服务器。 还可以使用硬件负载平衡器将特定于功能的流量引至专用于特定功能或服务的 Web 服务器。
容量管理与容量规划
容量管理对容量规划的概念进行了延伸，旨在表达一种循环方法，该方法通过持续监控和优化 SharePoint Server 2013 部署的容量，来适应不断变化的情况和要求。
SharePoint Server 2013 可提供更大的灵活性，并可以配置为维持多种不同规模的使用方案。 没有单个部署体系结构。 因此，系统设计人员和管理员必须了解特定环境的要求。
SharePoint Server 2013 容量管理模型
步骤 1：建模 建模是决定希望环境支持的关键解决方案并建立所有重要指标和参数的过程。 建模练习的输出应为设计环境所需要的全部关键数据的列表。
了解预期的工作负载和数据集。
设置服务器场性能和可靠性目标。
分析 SharePoint Server 2013IIS 日志。
步骤 2：设计 从步骤 1 中收集数据后，便可设计您的服务器场。 输出为详细的数据体系结构以及物理和逻辑拓扑。
确定起点体系结构。
选择硬件。
步骤 3：试验、测试和优化 如果您已设计新部署，则需部署用于测试工作负载和预期使用特征的试验环境。 对于现有的服务器场，建议在对基础结构做主要更改时进行测试，但为了维持性能目标，可能需要根据监视结果定期执行优化。 此阶段的输出是根据目标对测试结果的分析，以及能够实现设定的性能和容量目标的优化体系结构。
试验 部署试验环境。
测试 针对延迟和吞吐量目标进行测试。
优化 收集测试结果并对服务器场资源和拓扑进行任何所需的更改。
步骤 4：部署 此步骤介绍如何实现服务器场或向现有服务器场部署更改。 新设计的输出是到实时生产的已完成部署，包括所有内容和用户迁移。 现有服务器场的输出是修订的服务器场映射和对维护计划的更新。
步骤 5：监视和维护 此步骤介绍如何设置监视，以及如何预测和识别瓶颈并执行常规的维护和瓶颈缓解操作。
过大与过小
过大 描述一种服务器场设计方法，在该方法中，实现目标时未充分利用硬件，SharePoint Server 2013 服务器场中的资源长期、严重利用不足。 在过大部署中，内存、CPU 和服务器场资源的其他指示器表明，使用更少的资源可以很好地满足需求。 过大的缺点是增加了硬件和维护费用，并且会增大能源和空间需求。
过小 描述一种服务器场设计方法，在该方法中，由于 SharePoint Server 2013 服务器场中的硬件资源过度利用，因此无法实现性能和容量目标。 有时将服务器场设计得过小是为了降低硬件成本，但通常会导致延迟增加，从而影响用户体验、降低用户满足度、需要频繁升级、提高支持成本，并产生用于排除故障和优化环境的不必要花费。
设计服务器场时，请确保您的服务器场无论在正常高峰负载时还是在意外的瞬时峰值时均可满足设定的性能和容量目标。 设计、测试和优化将帮助您确保服务器场拥有合适的硬件。
为了满足性能目标并适应增长的需要，通常除了满足目标所需要的资源外，还需要具备一些资源。 与因设计过小导致的故障排除问题引发的累积费用相比，过度投资硬件的成本通常要低得多。
设置系统规模时，应始终使其可在高峰需求期间做出充分响应，这对于不同时间的特定服务而言可能有所不同。 为了有效估计容量要求，您需要确定所有资源的最差情况需求期。 在一天中的某些时候（如早晨或午饭后第一件事时），各个功能和服务的负载可能增加。
服务器场还必须能够支持计划外的高峰，例如，当发表组织范围的声明并且有非常多的用户同时访问网站时。 在此高需求期间，除非提供足够的服务器场资源来满足服务器场中增加的负载，否则用户会遇到高延迟，或根本得不到来自服务器场的响应。
当企业中要增加用户时，也应重新访问服务器场容量。 在进行合并或收购时，如果不提前进行规划和估计，访问服务器场的新员工或成员会对性能造成不利影响。
操作状态：绿色区域和红色区域
我们在描述生产系统的负载时，会引用两种主要操作状态："绿色区域"状态和"红色区域"状态。在绿色区域状态中，系统在正常、预期的负载范围内运行；在红色区域状态中，服务器场会经历非常高的瞬态资源需求，这种需求只能维持有限的时间段，此后会出现故障以及其他性能和可靠性问题。
绿色区域 在此状态中，服务器或服务器场在正常负载条件（最高为预期的每日高峰负载）下运行。 在此范围运行的服务器场应该能够将响应时间和延迟维持在可接受的参数范围内。
红色区域 此操作范围的负载大于正常高峰负载，但仍可在有限时间段内为请求提供服务。 此状态的特征是大于正常延迟和因系统瓶颈饱和引起的可能故障。
服务器场设计的最终目标是部署一个环境，该环境能够持续支持“红色区域”负载而不出现服务故障，并且符合可接受的延迟和吞吐量目标。
软件限制和边界
在 SharePoint Server 2013 中，存在一些根据设计要求不能超过的限制，以及其他可由服务器场管理员更改的设置为默认值的限制。 另外还有一些无法用可配置值表示的限制，如每个 Web 应用程序的网站集数。
边界是根据设计要求不能超过的绝对限制。 为确保您在设计服务器场时做出正确的假设，必须了解这些限制。
2 GB 的文档大小限制就是一个边界示例。 您无法将 SharePoint Server 2013 配置为存储大于 2 GB 的文档。 这是内置的绝对值，根据设计要求不能超出此值。
阈值是具有默认值的阈值，除非更改该值，否则不能超过该值。 在某些情况下，可以超出阈值以适应服务器场设计中的差异。 但是，必须了解，这样做可能会影响服务器场的性能和其他限制的有效值。
对于某些阈值的默认值，最多只能超过到绝对最大值。 文档大小限制还是一个恰当的示例。 默认情况下，文档大小限制设置为 50 MB，但可将其更改为最大值 2 GB。
支持的限制 定义给定参数的已测试值。 这些限制的默认值是通过测试定义的，表示产品的已知限制。 若超过支持的限制，可能会导致意外结果、严重降低性能或造成其他有害影响。
有些支持的限制是默认设置为建议值的可配置参数，而其他限制则与未由可配置的值表示的参数相关。
一个支持的限制示例是每个 Web 应用程序的网站集数。 支持的限制是在测试期间满足性能基准的每个 Web 应用程序可包含的最大网站集数。
重要的是要注意到，本文档中提供的很多限制值都表示曲线上的一点，该曲线描述不断增加的资源负载以及随值增大而降低的性能。 因此，超过某些限制（如每个 Web 应用程序的网站集数）可能只会导致服务器场性能的部分降低。 但是，在大多数情况下，在操作时达到或接近设立的限制不是一种最佳实践，因为只有在服务器场的设计留出合理的限制值余量时，才能最好地实现可接受的性能和可靠性目标。
阈值和支持的限制准则由性能确定。 换句话说，可以超过限制的默认值，但随着限制值的增加，场性能和其他限制的有效值可能会受到影响。 SharePoint Server 2013 中的许多限制可以更改。 但是，应了解更改给定限制如何影响服务器场的其他部分。
如果您就生产系统未满足SharePoint 2013 的硬件和软件要求 中所述的已发布最低硬件规格而联系 Microsoft 客户支持服务，则在系统升级以满足最低要求之前，提供的支持将是有限的。
如何建立限制
在 SharePoint Server 2013 中，通过对服务器场行为进行测试和观察，并不断增大负载直至达到最大值（服务器场服务和操作此时达到其有效的操作限制），从而建立阈值和支持的限制。 某些服务器场服务和组件可以比其他服务器场服务和组件支持更大的负载。 因此，在某些情况下，必须基于多个因素的平均值分配限制值。
例如，对添加网站集时的负载下的场行为的观察结果表明某些功能出现高得难以接受的滞后时间，而其他功能仍然运行在可接受的参数范围内。 因此，分配给网站集数的最大值不是绝对的，而是基于预期的使用特性集进行计算，其中整体场性能在大多数情况下在给定限制内均可接受。
如果运行某些服务所使用的参数高于限制测试所使用的参数，则其他服务的最大有效限制将降低。 因此，针对特定部署执行严格的容量管理和规模测试演练十分重要，这样才能为相应环境建立有效限制。
有关边界和限制及其如何影响容量管理过程的详细信息，请参阅 SharePoint 2013 的软件边界和限制。
SharePoint Server 2013 部署的重要区别
每个 SharePoint Server 2013 部署都有一组使其成为独特部署并不同于其他服务器场的重要特征。 可通过以下四个主要类别来描述这些重要区别：
规格 描述服务器场的硬件以及服务器场的拓扑和配置。
工作负载 描述服务器场中的需求，包括用户数和使用特征。
数据集 描述内容大小和分布。
运行状况和性能 根据延迟和吞吐量目标描述服务器场的性能。
规范
硬件
硬件是计算机的物理资源，如处理器、内存和硬盘。 硬件还包括物理网络组件，如 NIC（网络接口卡）、电缆、交换机、路由器和硬件负载平衡器。 通过确保使用正确硬件可以解决许多性能和容量问题。 反之，某个硬件资源使用不当（如服务器中的内存不足）会影响整个服务器场的性能。
拓扑
拓扑是服务器场硬件和组件的分布及其内部关系。 拓扑有两种类型：
逻辑拓扑 软件组件（如服务器场中的服务和功能）的地图。
物理拓扑 服务器和物理资源的地图。
通常，用户数和使用特征决定服务器场的物理拓扑，业务需求（如需要在预期负载下支持特定功能）驱动逻辑拓扑。
配置
我们使用配置这一术语来描述软件设置和参数设置情况。 而且，配置还指缓存、RBS、如何设置可配置的限制以及为了满足特定要求可进行设置或修改的软件环境的任何部分。
工作负荷
工作负载定义服务器场的主要操作特征，包括用户群、并发性、要使用的功能以及用于连接服务器场的用户代理或客户端应用程序。
不同的 SharePoint Server 2013 功能针对服务器场资源的关联成本也不同。 成本较高的功能的广泛应用可能会显著影响系统的性能和运行状况。 了解您的预期需求和使用特征有助于正确确定实现的规模，并可降低长期在不正常状况下运行系统的风险。
用户群
基于 SharePoint Server 2013 的应用程序的用户群是用户总数及其异地分布情况的组合。 而且，在总用户群内，还有一些用户子组可能比其他组更多地使用给定的功能或服务。 用户的并发性定义为在给定时间主动使用系统的用户的总百分比。 定义用户群的指示器包括唯一用户总数和并发用户数。
使用特征
服务器场的性能不仅受与系统交互的用户数影响，还受使用特征的影响。 根据用户访问服务器场资源的频率以及服务器场中是否启用了资源密集型功能和服务，用户数相同的两个组织可能具有显著不同的要求。 描述使用特征的指示器包括唯一操作的频率、整体操作组合 (读取和写入操作与管理操作) 的比例，以及针对场 (（如“我的网站”、“搜索”、“工作流”和 Office Online Server) ）启用的新功能的使用模式和负载。
数据集
系统中存储的内容量以及存储内容的体系结构的特征会显著影响系统的总体运行状况和性能。 了解数据的大小、访问频率和分布有助于您正确确定系统中的存储大小，并可防止其成为减慢用户与服务器场服务的交互速度并影响最终用户体验的瓶颈。
为了正确估计和设计基于 SharePoint Server 2013 的解决方案的存储体系结构，您需要了解系统中将存储的数据量以及将从不同数据源请求数据的用户数。 内容量是确定磁盘容量大小的一个重要要素，因为它会影响其他功能的性能，还可能会影响网络延迟和可用带宽。 定义数据集的指示器包括内容总大小、文档总数、网站集总数以及网站集的平均和最大大小。
运行状况和性能
SharePoint Server 2013 服务器场运行状况基本上是一种可反映系统可靠性、稳定性和性能的简化度量或评分方法。 服务器场针对目标的执行情况基本上依赖于前三个因素。 可以通过分解一组指示器来跟踪和描述运行状况和性能分值。 有关详细信息，请参阅监视和维护 SharePoint Server 2013 和 规划在 SharePoint 服务器监视。 这些指示器包括系统的正常运行时间、最终用户感知的延迟、页面失败率和资源利用率指示器（CPU、RAM）。
硬件、拓扑、配置、工作负载或数据集的任何重要更改都会显著改变系统的可靠性和响应速度。 运行状况分值可用来跟踪系统在一段时间内的性能，以及评估更改操作条件或系统修改对服务器场可靠性有何影响。
参考体系结构
SharePoint Server 2013 是一款复杂而强大的产品，没有通用型的体系结构解决方案。 每个 SharePoint Server 2013 部署都是唯一的，通过其使用和数据特征来定义。 每个组织都需要执行周密的容量管理过程，并有效利用 SharePoint Server 2013 系统提供的灵活性来自定义规模合适的解决方案，从而尽最大可能满足组织需要。
参考体系结构的概念旨在描述和说明 SharePoint Server 2013 部署的各个主要类别，而不是为架构师提供用于设计解决方案的方法。 本节重点介绍 SharePoint Server 2013 部署进行缩放时通常基于的矢量。
通过此处列出的体系结构，可以充分了解这些常见类别之间的区别，并根据一般的成本因素和工作量规模来对其进行区分。
单一服务器部署
单一服务器部署体系结构由一台运行 SharePoint Server 2013 和 SQL Server 受支持版本的服务器构成。 此体系结构可能适用于评估用途、开发人员或者只有少数用户的非任务关键型的单独部门实现。 但是，建议不要将其用于生产环境。
小型服务器场部署
小型服务器场部署由一台数据库服务器或群集与一台或两台基于 SharePoint Server 2013 的计算机组成。 主要体系结构特征包括有限的冗余和故障转移，并且启用了最少的一组 SharePoint Server 2013 功能。
小型服务器场只用于为有限的部署提供服务，此类部署启用了最少的一组服务应用程序，具有相对较小的用户群、相对较低的使用负载（每分钟几个请求，最多每秒钟几个请求）以及相对较少的数据量（10 GB 或更多）。
中型服务器场部署
此体系结构将拓扑细分为三层：专用的 Web 服务器、专用的应用程序服务器以及一个或多个数据库服务器或群集。 将前端服务器层与应用程序服务器层隔离可在服务隔离中获得更大的灵活性，并有助于平衡整个系统的负载。
这是最常用的体系结构，包括多种服务拓扑和服务器场规模。 中型服务器场部署可为具有以下特点的环境提供服务：
若干个服务应用程序分布于多台服务器上。 一组典型的功能可能包括 Office Online Service、User Profile Service、Managed Metadata Service 和 Excel Calculation Service。
用户群为数万名用户，负载为每秒 10 到 50 个请求。
数据存储为 1 TB 或 2 TB。
大型服务器场部署
大型服务器场部署引入了以下功能：可在多个服务器场中细分服务和解决方案，以及以单个服务器场为基础进一步向外扩展层。 可在为来自多个正在使用的服务器场的请求提供服务的一个专用服务场中部署若干个 SharePoint Server 2013 服务。 在这些大型体系结构中，通常存在 Web 服务器、多台应用程序服务器（具体取决于每个本地（非共享）服务的使用特征）以及多个基于 SQL Server 的服务器或 SQL Server 群集（取决于内容大小和在服务器场中启用的应用程序服务数据库）。 预计大型服务器场体系结构可为具有以下特征的部署提供服务：
从专用服务场中联合并使用的多个服务应用程序，通常包括 User Profile Service、Search Service、Managed Metadata Service 和 Web Analytics Service。
大多数其他服务应用程序都在本地启用。
用户群的范围是数百或数千名用户。
使用负载的范围是每秒数百个请求。
数据集的范围是 10 TB 或更多。
另请参阅
概念
性能和容量测试结果和建议 (SharePoint Server 2013)
其他资源
Performance and capacity technical case studies (SharePoint Server 2010)