评估部门协作环境的性能和容量要求 (SharePoint Server 2013)
适用于：
2013 
2016 2019 订阅版 SharePoint in Microsoft 365
本文介绍基于 SharePoint Server 2013 的部门协作解决方案的性能和容量规划指南。 本文包含以下信息：
测试实验室环境规范，例如硬件、服务器场拓扑和配置
用于生成测试负载的测试服务器场工作负载和数据集
用于演示和解释在特定规模的负载下吞吐量、延迟和硬件要求中的趋势的测试结果和分析。
使用本文中的信息了解正常和高峰负载下方案的特征，以及在服务器场扩展时性能趋势的变化方式。本文还可以帮助您为计划的体系结构评估一个合适的起点，并了解哪些事项是您在制定计划以在高峰负载下维持可接受的性能级别时应考虑的。
简介
本文概述了如何在 SharePoint Server 2013 分区协作解决方案中横向扩展服务器。 部门协作解决方案是 SharePoint Server 2013 部署，与企业协作解决方案相比，参与协作活动的计算机更少。 本文假设“部门”是拥有 1000 至 10000 名员工的企业中的组织。
不同的应用场景拥有不同的要求。 因此，通过在您自己的环境中，在您自己的硬件上进行测试来补充此指南。 如果您规划的设计和工作负载与本文中描述的环境相似，您可以得出扩展您的环境时预期性能的相关结论。
重要
这些文章中显示的测试结果是在使用模拟高度控制条件下生产环境的工作负载、数据集和体系结构的测试实验室内产生的。 即使在设计这些测试时非常小心，测试实验室的性能特征也永远不会与生产环境的行为相同。 这些测试结果不表示生产服务器场的性能和容量特征。 相反，测试结果将演示吞吐量、延迟和硬件要求中的观察趋势。 使用观察数据的分析帮助您规划容量和管理您自己的服务器场。
阅读本文时，您将了解到以下内容：
规范，包括硬件、拓扑和配置
工作负载，包括服务器场要求的分析、用户数和使用特征
数据集，例如数据库大小和内容类型
扩展 Web 服务器的测试结果和分析
在阅读本文之前，请阅读以下文章，确保了解 SharePoint 2013 SharePoint Server 2013 的软件边界和限制中容量管理背后的关键概念。
术语表
以下列表包含本文可找到的关键术语的定义。
RPS： 每秒请求数。 RPS 是场或服务器在一秒内收到的请求数。 这是测量服务器和服务器场负载的常用方法。
注意
请求不同于页面加载。 页面包含若干个组件，在加载页面时每个组件会创建一个或多个请求。 因此，一个页面加载会创建多个请求。 通常，使用身份验证检查和使用次要资源的事件不会计算在 RPS 测量中。
绿色区域： 绿色区域表示在正常运行条件下定义的一组负载特征，达到预期的每日峰值负载。 在此范围运行的服务器场应该能够将响应时间和延迟维持在可接受的参数范围中。
在此状态下，服务器可以保持以下设置条件：
至少 75% 的请求的服务器端延迟小于 1 秒。
所有服务器场都将平均 CPU 使用率保持在 60% 以下。
注意
我们的实验室环境未运行活动搜索爬网。 因此，我们将数据库服务器的 CPU 使用率保持在接近 50% 或更低，以保留 10% 的搜索爬网负载。 此操作假设生产中使用了 SQL Server 资源管理器，以将搜索爬网负载限制为 10% CPU。
失败率低于 0.01%。
红色区域 (最大) ： 红色区域表示在高峰运行条件下定义的一组负载特征。 在红色区域中，服务器场经历非常高的短暂资源需求，在故障和其他性能及可靠性问题发生之前，该需求仅可以持续限定的时间。
在此状态下，服务器可以保持以下设置条件一段时间：
已启用 HTTP 请求限制功能，但是未返回任何 503 错误（服务器繁忙）。
失败率低于 0. 1%。
至少 75% 的请求的服务器端延迟小于 3 秒。
所有服务器场（数据库服务器除外）都将平均 CPU 使用率保持在约 90% 以下。
数据库服务器平均 CPU 使用率小于 50%，以便为搜索爬网负载留出足够的开销。
AxBxC (Graph 表示法) ： 场中 Web 服务器、应用程序服务器和数据库服务器的数量。 例如，10x1x1 意味着此环境包含 10 个 Web 服务器、1 个应用程序服务器和 1 个数据库服务器。
MDF 和 LDF： SQL Server 物理文件。 有关详细信息，请参阅 文件和文件组体系结构。
概述
本节提供了扩展方法和测试拓扑的概述。
扩展方法
本节介绍了我们采用的扩展我们实验室环境的方法。 此方法使您可以找到最佳的工作负载配置：
我们扩展了 Web 服务器，直到使用四个 Web 服务器。 每个服务器都运行分布式缓存服务。
添加运行分布式缓存服务的专用服务器。
禁用 Web 服务器上的分布式缓存服务。
将其他 Web 服务器扩展到测试范围的最大值。
方法和测试说明
由于本文包含测试实验室环境的结果，我们可以控制某些因素来显示此工作负载的特定方面的性能。 此外，某些生产环境的元素（在下面的列表中列出）被排除在实验室环境之外，以减少测试环境的开销。
注意
建议您将这些元素包括在生产环境中。
在测试运行期间，我们一次仅修改一个变量，以便轻松地比较测试运行之间的结果。
数据库服务器不是集群的一部分，因为就这些测试的目的而言，冗余不是必要的。
测试期间未运行搜索爬网。 当然，它可能正在生产环境中运行。 考虑到这一点，我们在“绿色区域”和“红色区域”的定义中降低了SQL Server CPU 使用率，以适应搜索爬网在测试期间通常会使用的资源。
规格
本节提供了有关我们测试实验室环境的硬件、软件、拓扑和配置的详细信息。
硬件
本节介绍了我们测试实验室环境中使用的硬件。
重要
我们使用 Hyper-V 主机来虚拟化测试实验室中的所有 Web 服务器和应用程序服务器。 数据库服务器没有被虚拟化。 物理主机硬件和虚拟机虚拟硬件在本节中分别说明。
Hyper-V 主机
我们使用了六台配置相同的 Hyper-V 主机进行测试。 每个主机运行一到两台虚拟机。
| 主机硬件 | 值 |
|---|---|
| 处理器 |
2 个四核 2.49 GHz 处理器 |
| RAM |
32 GB |
| 操作系统 |
Windows Server 2008 R2 SP1 |
| 网络适配器数量 |
2 |
| 网络适配器速度 |
1 GB |
虚拟 Web 服务器和应用程序服务器
我们的测试服务器场使用八台虚拟 Web 服务器。 我们还使用运行分布式缓存服务的专用服务器。
注意
生产环境通常会使用高度可用的配置来部署运行分布式缓存服务的专用服务器。 在我们的测试实验室环境中，我们将单个专用服务器用于分布式缓存，因为高可用性并非关键因素。
| VM 硬件 | WFE1-8 和 DC1 |
|---|---|
| 处理器 |
4 个虚拟处理器 |
| RAM |
12 GB |
| 操作系统 |
Windows Server 2008 R2 SP1 |
| SharePoint 驱动器的大小 |
100 GB |
| 网络适配器数量 |
2 |
| 网络适配器速度 |
10 GB（主机间的流量受到主机网络适配器速度的限制） |
| 身份验证 |
Windows NTLM |
| 负载平衡器类型 |
F5 Big IP |
| 本地运行的服务 |
WFE 1-8：基本的联合服务。 这包括：SharePoint 计时器服务、跟踪服务、Word 自动化服务、Excel Services和 Microsoft SharePoint Foundation 沙盒代码服务。 DC1：分布式缓存服务。 |
数据库服务器
在我们的测试中，我们使用一个物理数据库服务器，并运行存储 SharePoint 数据库的默认 SQL Server 实例。 我们不跟踪本文中的日志记录数据库。
注意
如果您启用使用情况报告，建议您将日志记录数据库存储在单独的逻辑单元 (LUN) 中。 大型部署和某些中型部署可能要求专用日志记录数据库来满足生成大量日志记录事件的处理器需求。
在实验室环境中，我们约束日志记录，并将日志记录数据库存储在单独的 SQL Server 实例中。
| 数据库服务器 - 默认的实例 | SQL Server |
|---|---|
| 处理器 |
4 个四核 2.4 GHz 处理器 |
| RAM |
32 GB |
| 操作系统 |
Windows Server 2008 R2 SP1 |
| 存储和几何图形 |
直接附加存储 (DAS) 1 x 系统卷（RAID0，1 个心轴，300 GB） 2 x 内容数据卷（RAID0，4 个心轴，每个 450 GB） 2 x 内容日志卷（RAID0，2 个心轴，每个 450 GB） 1 x 临时数据卷（RAID0，2 个心轴，每个 300 GB） 1 x 临时日志卷（RAID0，2 个心轴，每个 300 GB） |
| 网络适配器数量 |
1 |
| 网络适配器速度 |
1 GB |
| 身份验证 |
Windows NTLM |
| 软件版本 |
SQL Server 2008 R2 |
拓扑
下图显示了我们测试实验室环境中的拓扑。
配置
下表显示了我们在实验室环境中对数据库服务器所做的重大配置更改。 这些配置更改可实现最佳测试性能，并明确测试参数与结果之间的关系。 请注意，SharePoint Server 2013 需要 MAXDOP 设置。 其他设置更改仅适用于测试实验室环境，不会影响生产环境。
| 设置 | 值 | 注释 |
|---|---|---|
| 网站集 |
179（环境中总计） |
我们测试环境中的网站集使用默认的设置和 Windows 声明身份验证。 |
| BLOB 缓存 |
开 |
默认设置为禁用。 如果您启用 BLOB 缓存，您可以通过降低对数据库服务器的调用（用于浏览器可能经常请求的静态页面资源），提高服务器效率。 |
| 最大并行度 (MAXDOP) |
1 |
可在 SQL Server 实例或包含 SharePoint Server 2013 内容数据库的实例上设置此参数。 默认值为 0，它将启用 SQL Server 来确定最大并行度。 SharePoint Server 2013 要求为包含 SharePoint Server 2013 数据库的 SQL Server 实例将 MAXDOP 设置为 1。 有关如何为 SQL Server 2008 R2 配置 MAXDOP 设置的信息，请参阅最大并行度选项。 有关如何为 SQL Server 2012 配置 MAXDOP 设置的信息，请参阅配置最大并行度服务器配置选项。 |
Workload
本部分介绍针对 SharePoint Server 2013 运行的实验室测试。 测试的详细信息构成了典型的企业协作环境。
数据集
我们用于测试实验室环境的数据集是典型部门协作环境的代表。 此数据集包含各种网站集、网站、列表、库、文件类型和文件大小。
| 数据集特征 | 值 |
|---|---|
| 数据库大小（组合） |
174 GB |
| MDF 大小 |
154 GB |
| LDF 大小 |
20 GB |
| BLOB 大小 |
152 GB |
| 内容数据库的数量 |
2 |
| 网站集的数量 |
179 |
| Web 应用程序的数量 |
1 |
| 网站的数量 |
1,471 |
结果和分析
以下结果根据概述部分中描述的扩展方法进行了排序。
Web 服务器扩展
以下章节介绍了我们在我们实验室环境中扩展 Web 服务器数量时所获得的测试结果。
测试方法
添加使用相同硬件规范的 Web 服务器，然后在不更改服务器场或测试参数的情况下再次运行测试。
测量测试服务器场中每个服务器上的 RPS、延迟和资源使用率。
分析
在我们的测试中，我们发现了以下现象：
可将环境扩展为每台数据库服务器 10 台 Web 服务器。 吞吐量呈相对线性增长。
即使达到 10 台 Web 服务器的最大测试规模，添加更多的数据库服务器也不会增加吞吐量。 该瓶颈通常是由 Web 服务器资源的局限性造成的。
在整个测试中绿色区域的平均延迟几乎是恒定的。 Web 服务器的数量和吞吐量不会影响绿色区域延迟。 红色区域延迟数据显示预期的趋势线。 单个 Web 服务器中的延迟值会很高。 介于 2 和 8 之间的 Web 服务器曲线不会超出红色区域标准。
注意
当您将分布式缓存服务从服务器场的 Web 服务器移至专用的分布式缓存服务器时，可能稍微会对延迟造成影响。 发生此情况的原因可能是因为，先前位于每个 Web 服务器内部的分布式缓存流量会开始穿过网络。 在您自己的环境中测试扩展性能以确定这样的权衡是否重要。 请注意，将分布式缓存服务迁移到专用服务器时，测试环境中的延迟会稍微增长。 延迟会随着每个 Web 服务器的添加而降低，这是因为名义上增加的延迟会因 Web 服务器上处理和内存负载的减少而被抵消。 > 有关分布式缓存容量规划的详细信息，请参阅 在 SharePoint Server 中规划源和分布式缓存服务。
由于 SharePoint Server 2013 中缓存和数据库使用特征的改进，数据库服务器层上的平均负载较低。 我们发现无需在测试期间扩展数据库服务器。
当您根据主机硬件资源和同一主机上运行的其他虚拟计算机上的资源使用率，添加虚拟 Web 服务器时，性能将增加。 虚拟服务器要求额外的特定于虚拟化的规划和管理策略。
有关 Hyper-V 性能和容量规划的详细信息，请参阅 SharePoint 2013 的 Hyper-V 虚拟化要求 和使用 SharePoint 2013 虚拟机和 Hyper-V 环境的最佳做法配置。
注意
本节中的结果特定于构成环境的硬件。 如果环境使用的 Hyper-V 主机服务器较多但功能较弱，或者 Hyper-V 主机服务器较少但功能更强，则环境可能已实现相同的吞吐量。 数据库服务器上硬件资源的增加不会给结果造成重大影响。
结果、图形和图表
下面图形中的 x 轴显示服务器场中 Web 服务器数量的变化。 该规模一开始使用 1 个虚拟 Web 服务器和一个物理数据库服务器 (1x1)。 最大值为 8 个虚拟 Web 服务器、一个专用虚拟分布式缓存服务器（在达到 4 个 Web 服务器时添加的）和一个物理数据库服务器 (8x1x1)。
注意
本节中的图形表示测试期间每个数据点的平均值。 所有图形均包括用于绿色和红色区域的 RPS 基线，用来显示 RPS 和诸如延迟、服务器资源使用率以及 SQL Server 磁盘使用率等因素之间的关系。
1. RPS
下图显示了扩展将如何影响 RPS 基线。
2. 延迟
下图显示了扩展如何影响延迟。 请注意绿色区域延迟大多呈平整状态，而红色区域延迟则会在可接受的限制范围内出现增长。
3. Web 服务器处理器和内存使用率
下图显示了扩展如何影响 Web 服务器上的处理器和内存的平均使用率。 请注意绿色区域中的处理器使用率和平均内存使用率会随着 RPS 的增加而保持相对恒定。
红色区域中的处理器使用率的趋势是向下的。 向下趋势反映了在最大负载下，Web 服务器的处理器平均需求量会随着服务器数量的增加而递减。
4. SQL Server每秒 I/O 操作数 (IOPS) 和处理器使用率
下图显示平均的磁盘 IOPS（总数和读取/写入数）和处理器使用率值会随着 Web 服务器数量的扩展而发生改变。我们使用下面的性能计数器测量 IOPS 值：
PhysicalDisk: 磁盘读取数/秒
PhysicalDisk: 磁盘写入数/秒
将计算出测试期间每个计数器值的平均值，然后通过加在一起以生成 IOPS 总数。
注意
由于SQL Server内存利用率的数据在测试时不可用，因此此数据不包括在此图中。
重要
这些 IOPS 测试结果不代表生产环境，因为我们的数据集比生产服务器场要小得多。 与生产环境相比，Web 服务器或许能够缓存更大比例的数据。 因为我们在 Web 服务器缓存更大比例的数据，因此，本节中的 IOPS 结果是基于可用测试数据得出的平均值。 我们预计我们的 IOPS 结果通常小于生产环境中的 IOPS。 在试验环境中全面测试您自己的服务器场可能会产生不同的结果。
请注意在本节中的图表中，IOPS 和数据库服务器处理器使用率在 6 台前端 Web 服务器时会出现下降，但 RPS 仍将继续增长。 此变化也会反映在 Web 服务器处理器使用率中，如前面的图形中所示。
这显示服务器场的规模已经达到一个界点，即此时因使用基线负载和数据集而对服务器场资源形成的压力已达到最大值。 要求使用较低的服务器资源使用率平均值来支持服务器场上的负载。
可从此趋势得出以下结果：
如果在第六个 Web 服务器规模点处增加测试负载，也能达到更大的 RPS，同时使服务器资源使用率仍保持为一条较平的曲线。
如果进一步扩展 Web 服务器的数量并维持相同的测试负载，RPS 将继续增加，同时服务器资源上的压力将继续呈现下行趋势。
SQL Server IOPS 总数
下图显示了扩展将如何影响 IOPS 总数。
SQL Server IOPS 细分为读取和写入操作
下图显示了扩展将如何影响 IOPS（每秒读取数和每秒写入数）。
SQL Server处理器使用率
下图显示了扩展将如何影响 SQL Server 处理器使用率。
