评估社交环境的性能和容量要求 (SharePoint Server 2013)
**上一次修改主题：**2017-08-25
**摘要：**了解在为"我的网站"和基于 SharePoint Server 2013 的社会计算门户规划容量时，如何确定您所需要的计算机的数量和类型。
要为企业 Intranet"我的网站"和社交计算门户解决方案创建性能和容量计划，本文包含有关以下方面的信息：
实验室环境规范，例如硬件、服务器场拓扑和配置
用于生成测试负载的测试服务器场工作负载和数据集
用于演示和解释在特定规模的负载下吞吐量、延迟和硬件要求中的趋势的测试结果和分析。
使用本文中的信息了解下列概念：
在正常和峰值负载下的方案特征
当横向扩展场服务器时性能趋势有何变化
如何评估您计划的体系结构的适当起点
当您规划您的服务器场在峰值负载下维护可接受的性能级别所需的资源时要考虑的重要因素
本文内容：
此环境的介绍
术语表
概述
规范
结果和分析
此环境的介绍
企业通常使用SharePoint Server 2013来将我的网站和社交计算门户的经过身份验证的用户访问 intranet 站点上的发布。本文有助于计划使用的计算机的数量和类型的需要在SharePoint Server 2013中发布我的网站和社交计算门户的计算机的容量和性能数据。
其他指导说明如何扩张中的SharePoint Server 2013企业我的网站和社交计算的门户解决方案的服务器。容量规划通知有关硬件采购和系统优化解决方案的配置决定。
因为单个SharePoint Server 2013场是唯一的每场都有不同要求，这取决于硬件、 用户行为、 已安装的功能的配置和许多其他因素。因此，补充其他测试您自己的环境在硬件上与本指南。如果您计划的设计和工作负荷类似于本文中描述的环境，可以使用本文得出关于如何扩展您的环境的结论。
这些文章中显示的测试结果是在使用模拟高度控制条件下生产环境的工作负载、数据集和体系结构的测试实验室内产生的。即使在设计这些测试时非常小心，测试实验室的性能特征也永远不会与生产环境的行为相同。这些测试结果不表示生产服务器场的性能和容量特征。相反，测试结果将演示吞吐量、延迟和硬件要求中的观察趋势。使用观察数据的分析帮助您规划容量和管理您自己的服务器场。
本文包含以下内容：
规范，包括硬件、拓扑和配置
工作负载，包括服务器场要求的分析、用户数和使用特征
数据集，例如数据库大小和内容类型
扩展 Web 服务器的测试结果和分析
在阅读本文之前，请阅读以下文章，以确保您了解在SharePoint Server 2013的容量管理的重要概念。
这些文章提供以下信息：
容量管理的推荐方法
如何有效利用本文中的信息
术语表
以下列表包含本文可找到的关键术语的定义。
**RPS：**每秒请求数。RPS 是服务器场或服务器每秒接受的请求数。这是测量服务器和服务器场负载的常用方法。
重要
请注意，请求不同于页面加载。每个页面包含若干个组件，在加载页面时每个组件会创建一个或多个请求。因此，一个页面加载会创建多个请求。通常，使用身份验证检查和使用次要资源的事件不会计算在 RPS 测量中。
**绿色区域：**绿色区域表示正常操作条件（最高为预期的每日高峰负载）下定义的负载特征集。在此范围运行的服务器场应该能够将响应时间和延迟维持在可接受的参数范围中。
在此状态下，服务器可以保持以下设置条件：
至少 75% 的请求的服务器端延迟小于 0.5 秒。
所有服务器都将平均 CPU 使用率保持在 50% 以下。
失败率低于 0. 1%。
**红色区域（最大）：**红色区域表示高峰操作条件下定义的负载特征集。在红色区域中，服务器场经历非常高的短暂资源需求，在故障和其他性能及可靠性问题发生之前，该需求仅可以持续限定的时间。
在此状态下，服务器可以保持以下设置条件一段时间：
至少 75% 的请求的服务器端延迟小于 1 秒。
数据库服务器的平均 CPU 利用率小于 80%。
失败率低于 0. 1%。
概述
本节总结了我们的扩展方法、此实验室环境和类似的案例研究环境之间的关系以及我们的测试方法。
扩展方法
我们建议您按扩展测试实验室环境的相同顺序，扩展您的环境中的计算机。此方法将使您能够找到您的工作负载的最佳配置。
我们将性能测试周期分为三个工作负载类别。确定类别边界的主要参数为用户配置文件的数量，这设置为 10,000、100,000 和 500,000 个用户配置文件测试。另一个参数是执行与社交功能集相关的操作的活动用户数量。在知道具有配置文件的用户数量和活动用户数量的情况下，我们运行测试，以模拟与实际部署类似的应用程序使用情况。下表介绍了初始数据集和活动用户数量。
初始数据集
| 实体 | 具有此功能的用户的百分比 | 小型（10,000 名用户） | 中型（100,000 名用户） | 大型（500,000 名用户） |
|---|---|---|---|---|
用户的用户配置文件数量 |
100% |
10K |
100K |
500K |
配置的"我的网站"数量 |
100% |
10K |
100K |
500K |
具有用户照片的用户配置文件的数量 |
50% |
5K |
50K |
250K |
具有帖子的用户配置文件的数量 |
10% |
1K |
10K |
50K |
团队数量 |
1,860 |
18,600 |
93K |
|
每天的活动用户数量 |
10% |
1K |
10K |
50K |
每小时的活动用户数量 |
5% |
500 |
5K |
25K |
测试着重于下列关键方案：
新闻源页面访问以及其他操作
配置文件页
站点源页面访问以及其他操作
Outlook Social Connector 活动源同步
OneDrive for Business 页面访问
OneDrive for Business 客户端使用情况
为了模拟真实的部署方案，所有测试均在已具有数据的数据库上运行。数据集是每个团队平均有 4-6 名用户，深度为 3-4 个级别的树组织的模型。为了生成这些数字，我们分析了内部社交网站中的流量。下表介绍了用于构建初始数据集的参数集。
初始数据库的数据模型
| 数据实体说明 | 数量 |
|---|---|
团队中的平均用户数量 |
5 |
每个组织的平均级别数量 |
4 |
每 1,000 名用户的团队数量 |
186 |
用户关注的平均同事数量 |
50 |
用户配置文件属性的数量 |
93 |
下表介绍了与可能导致数据填充的操作有关的参数集：
使用特征
| 参数 | 数量或百分比 |
|---|---|
具有 1-3 篇帖子的用户的百分比 |
10% |
每个用户的平均帖子数量 |
2 |
每篇帖子的平均回复数量 |
2 |
被关注的帖子的百分比 |
15% |
具有链接的帖子的百分比 |
5% |
具有标记的帖子的百分比 |
12% |
提到用户的帖子的百分比 |
8% |
附加了图像的帖子的百分比 |
5% |
为了创建每个扩展测试，我们将以下操作组合应用到了前一数据集和活动用户数量：
用户读取操作
| 用户操作 | 执行此操作的用户的百分比 | 方案 | 功能或 URL |
|---|---|---|---|
导航到"我的网站"主页 |
12% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
导航到用户的公共配置文件页面 |
8% |
配置文件 |
配置文件页面 (http://my/person.aspx?accountname=<alias>) |
导航到用户的个人配置文件页面 |
4% |
配置文件 |
配置文件页面 (http://my/person.aspx) |
活动源自动同步 |
32% |
Outlook Social Connector |
无 |
导航到"我关注的人"页面 |
3% |
关注人员列表 |
http://my/MyPeople.aspx |
导航到默认文档库 |
6% |
OneDrive for Business |
https://msft-my.spoppe.com/personal/<user>/Documents |
导航到关注的文档页面 |
3% |
OneDrive for Business |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
导航到关注的文档页面 |
3% |
OneDrive for Business |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
导航到站点源页面 |
8% |
站点源 |
站点源页面 (https://<domain>/teams/<site>/newsfeed.aspx_ |
查看对帖子的所有答复 |
1% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
查看"任何人"源 |
3% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
查看新闻源上的更多帖子 |
2% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
查看 @mentions 页面 |
1% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
查看新闻源（移动） |
1% |
移动 |
移动表述性状态转移 (REST) 调用 |
查看分类新闻源 |
3% |
移动 |
移动 REST 调用 |
用户写入操作
| 用户操作 | 百分比 | 方案 | 功能或 URL |
|---|---|---|---|
在源中创建根帖子 |
0.5% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
关注源中的帖子 |
0.3% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
回复源中的帖子 |
0.7% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
在包含 @mention 的源中创建帖子 |
0.1% |
新闻源 |
新闻源页面 (http://my/default.aspx) |
在站点源中创建根帖子 |
0.5% |
站点源 |
站点源页面 (https://<domain>/teams/<site>/newsfeed.aspx) |
在包含 @mention 的站点源中创建帖子 |
0.5% |
站点源 |
站点源页面 (https://<domain>/teams/<site>/newsfeed.aspx) |
回复站点源中的帖子 |
0.15% |
站点源 |
站点源页面 (https://<domain>/teams/<site>/newsfeed.aspx) |
在包含标记的站点源中创建帖子 |
0.05% |
站点源 |
站点源页面 (https://<domain>/teams/<site>/newsfeed.aspx) |
OneDrive for Business 客户端操作
| 用户操作 | 百分比 | 方案 | 功能或 URL |
|---|---|---|---|
OneDrive for Business 初始同步 |
0.2% |
OneDrive for Business |
初始同步 |
OneDrive for Business 增量同步 - 下载文件 |
0.88% |
OneDrive for Business |
增量同步 |
OneDrive for Business 增量同步 - 无更改 |
8.1% |
OneDrive for Business |
增量同步 |
测试方法
我们开始与社会功能的最小SharePoint Server 2013服务器场配置。我们应用于测试场的特征的社会负载和增加负载，直到我们观察到的普通和最大服务器容量的级别。我们分析每种负载级别和横向扩展的服务器场配置的重载角色添加的计算机的瓶颈。此添加缓解每个用例中的瓶颈，为特定的数据集提供服务器的可伸缩性特征的视图。我们重复三个部署规模提供SharePoint Server 2013服务器场的可扩展性特性的具有代表性的摘要为此向外扩展过程和指导原则进行容量规划。
规格
本节提供有关实验室环境的硬件、软件、拓扑和配置的详细信息。
重要
已使用 Hyper-V 主机虚拟化了测试实验室中的所有 Web 服务器和应用程序服务器。未虚拟化数据库服务器。物理主机硬件和虚拟机虚拟硬件在下面各节分别进行了详细介绍。
硬件
下表列出了此测试中使用的计算机的硬件规格。在多次测试迭代中添加到服务器场的前端 Web 服务器也符合这些规格。
Hyper-V 主机
服务器场总共包括三台配置相同的 Hyper-V 主机，每台主机运行一到四台虚拟机。
| 主机硬件 | 值 |
|---|---|
处理器 |
2 个四核 2.27 GHz 处理器 |
RAM |
64 GB |
操作系统 |
Windows Server 2008 R2 SP1 |
网络适配器数量 |
2 |
网络适配器速度 |
1 GB |
虚拟 Web 服务器和应用程序服务器
服务器拥有 1 到 8 个虚拟 Web 服务器。一个额外的专用虚拟服务器运行分布式缓存服务。
备注
在生产环境中，通常会使用高度可用的配置来部署运行分布式缓存服务的专用服务器。出于测试目的，我们将单个专用服务器用于分布式缓存，因为高可用性并非关键因素。
| VM 硬件 | Web 服务器 |
|---|---|
处理器 |
4 个虚拟处理器 |
RAM |
12 GB |
操作系统 |
Windows Server 2008 R2 SP1 |
SharePoint 驱动器的大小 |
100 GB |
网络适配器数量 |
2 |
网络适配器速度 |
1 GB |
身份验证 |
Windows NTLM |
负载平衡器类型 |
F5 Big IP |
本地运行的服务 |
Microsoft SharePoint Foundation Web Application、Microsoft SharePoint Foundation Incoming E-Mail、Microsoft SharePoint Foundation Workflow Timer Service、Managed Metadata Web Service、User Profile Service |
| VM 硬件 | 缓存 |
|---|---|
处理器 |
4 个虚拟处理器 |
RAM |
12 GB |
操作系统 |
Windows Server 2008 R2 SP1 |
SharePoint 驱动器的大小 |
100 GB |
网络适配器数量 |
2 |
网络适配器速度 |
1 GB |
身份验证 |
Windows NTLM |
本地运行的服务 |
Distributed Cache、Microsoft SharePoint Foundation Workflow Timer Service |
| VM 硬件 | 搜索查询组件 |
|---|---|
处理器 |
4 个虚拟处理器 |
RAM |
12 GB |
操作系统 |
Windows Server 2008 R2 SP1 |
网络适配器数量 |
2 |
网络适配器速度 |
1 GB |
身份验证 |
Windows NTLM |
本地运行的服务 |
Microsoft SharePoint Foundation Web Application、Microsoft SharePoint Foundation Incoming E-Mail、Microsoft SharePoint Foundation Workflow Timer Service、Search Query and Site Settings Service、SharePoint Server Search |
| VM 硬件 | 搜索索引组件 |
|---|---|
处理器 |
4 个虚拟处理器 |
RAM |
12 GB |
操作系统 |
Windows Server 2008 R2 SP1 |
网络适配器数量 |
2 |
网络适配器速度 |
1 GB |
身份验证 |
Windows NTLM |
本地运行的服务 |
Microsoft SharePoint Foundation Web Application、Microsoft SharePoint Foundation Incoming E-Mail、Microsoft SharePoint Foundation Workflow Timer Service、SharePoint Server Search |
数据库服务器
一台物理数据库服务器运行具有 SharePoint 数据库的默认 SQL Server 实例。本文不介绍日志记录数据库。
备注
如果您启用使用情况报告，建议您将日志记录数据库存储在单独的逻辑单元 (LUN) 中。大型部署和某些中型部署可能要求专用日志记录数据库来满足生成大量日志记录事件的处理器需求。
在此实验室环境中，日志记录受到约束且日志记录数据库存储在单独的 SQL Server 实例中。
数据库服务器 – 默认的实例
处理器 |
2 个四核 3.3 GHz 处理器 |
RAM |
32 GB |
操作系统 |
Windows Server 2008 R2 SP1 |
存储和几何图形 |
直接附加存储 (DAS) 具有 6 x 300 GB 15krpm 磁盘的内部阵列 具有 15 x 450 GB 15krpm 磁盘的外部阵列 50 x 内容数据（外部 RAID10，2x3 轴，每个 300 GB） 50 x 内容日志（内部 RAID10，2x2 轴，每个 300 GB） 1 x 临时数据（内部 RAID10，2x2 轴，每个 300 GB） 1 x 临时日志（内部 RAID10，2x2 轴，每个 300 GB） |
网络适配器数量 |
1 |
网络适配器速度 |
1 GB |
身份验证 |
Windows NTLM |
软件版本 |
SQL Server 2008 R2 |
拓扑
下表显示了此实验室环境的拓扑：
实验室环境拓扑
| 角色 | 小型部署（10,000 名用户） | 中型部署（100,000 名用户） | 大型部署（500,000 名用户） |
|---|---|---|---|
Web 服务器 |
2-4 |
4-8 |
8 |
缓存 |
1 |
1-2 |
3 |
SQL Server |
1 |
1-2 |
2 |
测试过程
重要
-
测试仅模拟典型社交计算门户上的正常营业时间使用情况。我们不考虑日/夜周期产生的用户生成流量中的周期性变化。我们使用相同的测试工作负载分别测试计时器作业，例如配置文件同步和人员搜索爬网，以确定其效果。
-
测试重点在于社交操作，例如新闻源、社交标记和读取人员配置文件。测试组合包括少量的典型协作通信，以更好地模拟生产环境。我们希望这些测试将有助于设计一个专用于"我的网站"和社交功能的单独门户。
-
测试组合不包括搜索内容爬网通信。
我们针对用于社交功能的小型、中型和大型部署构建测试。为了配置服务器硬件，我们从最小部署的最低配置开始，并使用扩展方法一节中所述的数据集填充测试数据库。
我们使用 Visual Studio Team System (VSTS) 模拟工作负载并应用特征社交负载，在一开始就推动对服务器的小型负载。我们慢慢地统一增加此负载，并记录所有服务器角色上的性能指标，直到达到最大 RPS。这可以识别为是当增加对服务器场施加的负载时，由于服务器瓶颈限制导致交付的 RPS 输出没有增加时的状态。
根据这些记录的指标，我们定义了绿色区域和红色区域状态，分别代表指定计算机配置下 VM 服务器的正常和满载状态。然后我们在绿色区域和红色区域级别施加稳定负载，以分析这些负载的稳态性能指标。这提供了每种拓扑设置在这些关键负载条件下 VM 服务器的服务器运行状况和性能表示。
了解绿色和红色负载特征以及每种拓扑的扩展曲线后，我们确定了限制 RPS 的扩展瓶颈。对于社交工作负载，这通常是小型数据集的 Web 服务器 CPU。对于大型数据集，我们还观察了分布式缓存节点上的内存压力。我们在配置中增加了过载角色的虚拟服务器，移除每种情况的瓶颈并继续执行横向扩展过程。然后我们重复执行分析每个配置大小的性能趋势及其与绿色和红色区域定义符合性的过程，直到达到特定部署大小的要求。
了解每种部署大小后，我们按下一个较大大小的最低配置重新配置测试服务器场，按照扩展方法中所述填充了数据集，重复了分析/横向扩展过程周期，并测量了每个数据集大小的横向扩展特征。
结果和分析
此部分说明了三种部署大小的测量结果。具体地说，它介绍了通过添加 Web 服务器横向扩展服务器场对绿色和红色区域 RPS、延迟和平均 CPU 使用率有何影响。
下列趋势在所有三种部署大小中是一致的：
红色和绿色区域 RPS 随虚拟 Web 服务器的数量线性增加。
所有测试配置的主要瓶颈是 Web 服务器 CPU。
在红色区域中，在我们添加 Web 服务器并增加负载时延迟略有增加。这是由于 SQL Server 和分布式缓存服务（在测试服务器场中的所有 Web 服务器上运行）上的压力增加所致。
此外，SQL Server 和分布式缓存计算机上的平均 CPU 使用率随 Web 服务器数量的增加而增加。这是由于 SQL Server 和分布式缓存服务上的其他缓存负载所致。
随着 Web 服务器数量增加，绿色区域延迟仍保持平稳。这是因为 Web 服务器在绿色区域负载级别未过载。
小规模结果
下图显示了 Web 服务器数量增加对绿色区域和红色区域的 RPS 有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects RPS for both Green and RED zones in the 10k user scenario.")
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的延迟有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects latency for both Green and RED zones in the 10k user scenario.")
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的平均 CPU 使用率有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects CPU usage for both Green and RED zones in the 10k user scenario.")
中等规模结果
下图显示了 Web 服务器数量增加对绿色区域和红色区域的 RPS 有何影响。
.png "Screenshot showing how increasing the number of front-end-web servers affects RPS for both Green and RED zones in the 100k user scenario.")
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的延迟有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects latency for both Green and RED zones in the 100k user scenario.")
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的平均 CPU 使用率有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects CPU usage for both Green and RED zones in the 100k user scenario.")
大规模结果
下图显示了 Web 服务器数量增加对绿色区域和红色区域的 RPS 有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects RPS for both Green and RED zones in the 500k user scenario.")
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的延迟有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects latency for both Green and RED zones in the 500k user scenario.")
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的平均 CPU 使用率有何影响。
.png "Screenshot showing how increasing the number of front-end web servers affects CPU usage for both Green and RED zones in the 500k user scenario.")
随着 Web 服务器数量增加，将发生以下事件：
由于这些共享资源的负载增加，SQL Server 和分布式缓存节点的平均 CPU 使用率增加。
由于 SQL Server 和分布式缓存计算机的瓶颈略有偏移，红色区域的平均 Web 服务器 CPU 使用率略有下降。
绿色区域的平均 Web 服务器 CPU 使用率保持不变，因为服务器保持在建议的负载级别。
建议
成功的SharePoint Server 2013社会部署是度量的性能取决于以下因素：
您想支持的活动用户的数量
读取和写入操作的预期事务组合
负载在场服务器之间的分布
活动用户的预期数量是确定在拓扑中应规划的服务器数量的关键因素之一。活动用户数量还确定了承载跨服务器启用社交方案所需的各种服务的组成。
尽管我们的测试使用典型的数据集并应用您在实际客户部署中可能出现的负载复杂性，每个部署都是独一无二的。您的容量规划工作应考虑预期的使用特征、功能配置和硬件资源可用性。有些因素可能具有一定影响或大大改变容量数量，包括：
增加的电子邮件使用量模式可能增加 Outlook Social Connector 生成的负载。
事务组合中的写入操作百分比大大增加（例如标记或 @mention 增加）可能导致数据库服务器负载增加。
您可以添加或移除 Web 服务器以平衡 Web 服务器、SQL Server 和分布式缓存节点之间的 CPU 负载。
仔细按照标准SharePoint Server 2013配置指南，以获得最佳性能。专门为社会事务很重要的考虑因素如下：
配置文件数据库的单独物理磁盘 - 由于社交事务在配置文件数据库上的磁盘使用率较高，我们建议您在运行 SQL Server 的服务器上，将配置文件数据库保留在自己的物理磁盘集上。
User Profile Service 应用程序的内存要求 - User Profile Service 应用程序位于前端 Web 服务器上，它严重依赖于内存中的缓存。确保前端 Web 服务器具有足够的 RAM 以缓存大量数据请求。最小建议 RAM 为每个前端 Web 服务器 12 GB。
分布式缓存服务器的内存要求 - 社交功能（尤其是微博）主要依赖于充足和强大的分布式缓存。这些计算机上的内存太低可能会使 SharePoint 服务器场的容量下降，此缓存将重新填充。因此，我们建议您将承载分布式缓存的服务器配置为使用至少 12 GB RAM，并根据部署中的用户总数量，根据需要进行横向扩展。
SharePoint Server 2013社会部署会强制设置为想要使用社会功能的每个用户的个人网站。创建个人网站的内容数据库级别的增长规划。有关如何扩展个人网站集的详细信息，请参阅SharePoint 2013 的软件边界和限制。