评估社交环境的性能和容量要求 (SharePoint Server 2013)
适用于：
2013 
2016 2019 订阅版 SharePoint in Microsoft 365
要为企业 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 个用户配置文件测试。 另一个参数是执行与社交功能集相关的操作的活动用户数量。 在知道具有配置文件的用户数量和活动用户数量的情况下，我们运行测试，以模拟与实际部署类似的应用程序使用情况。 下表介绍了初始数据集和活动用户数量。
初始数据集
| Entity | 具有此功能的用户的百分比 | 小型（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 页面访问权限
OneDrive 客户端使用情况
为了模拟真实的部署方案，所有测试均在已具有数据的数据库上运行。 数据集是每个团队平均有 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=<别名>) |
| 导航到用户的专用配置文件页 |
4% |
配置文件 |
配置文件页 (http://my/person.aspx) |
| 活动源自动同步 |
32% |
Outlook Social Connector |
无 |
| 导航到“我关注人员”页 |
3% |
关注人员列表 |
http://my/MyPeople.aspx |
| 导航到默认文档库 |
6% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Documents |
| 导航到关注的文档页面 |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| 导航到关注的文档页面 |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| 导航到站点源页面 |
8% |
网站源 |
网站源页 (https://< 域>/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 客户端操作
| 用户操作** | 百分比 | 应用场景 | 功能或 URL |
|---|---|---|---|
| OneDrive 初始同步 |
0.2% |
OneDrive |
初始同步 |
| OneDrive 增量同步 - 下载文件 |
0.88% |
OneDrive |
增量同步 |
| OneDrive 增量同步 - 无更改 |
8.1% |
OneDrive |
增量同步 |
测试方法
我们从社交功能的最低 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 |
拓扑
下表显示了此实验室环境的拓扑：
实验室环境拓扑
| Role | 小型部署（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 服务器并增加负载时延迟略有增加。 这是由于测试场) 中所有 Web 服务器上运行的SQL Server和分布式缓存服务 (增加了压力。
此外，SQL Server和分布式缓存计算机上的平均 CPU 使用率会随着 Web 服务器数量的增加而增加。 这是由 SQL Server 上的 和分布式缓存服务上的额外缓存负载引起的。
随着 Web 服务器数量增加，绿色区域延迟仍保持平稳。 这是因为 Web 服务器在绿色区域负载级别未过载。
小规模结果
下图显示了 Web 服务器数量增加对绿色区域和红色区域的 RPS 有何影响。
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的延迟有何影响。
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的平均 CPU 使用率有何影响。
中等规模结果
下图显示了 Web 服务器数量增加对绿色区域和红色区域的 RPS 有何影响。
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的延迟有何影响。
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的平均 CPU 使用率有何影响。
大规模结果
下图显示了 Web 服务器数量增加对绿色区域和红色区域的 RPS 有何影响。
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的延迟有何影响。
下图显示了 Web 服务器数量增加对绿色区域和红色区域负载级别的平均 CPU 使用率有何影响。
随着 Web 服务器数量增加，将发生以下事件：
由于增加了这些共享资源的负担，SQL Server和分布式缓存节点的平均 CPU 使用率会增加。
红色区域的平均 Web 服务器 CPU 使用率略有下降，因为瓶颈会稍微转移到SQL Server和分布式缓存计算机。
绿色区域的平均 Web 服务器 CPU 使用率保持不变，因为服务器保持在建议的负载级别。
建议
成功的 SharePoint Server 2013 社交部署（按性能衡量）取决于以下因素：
您想支持的活动用户的数量
读取和写入操作的预期事务组合
负载在场服务器之间的分布
活动用户的预期数量是确定在拓扑中应规划的服务器数量的关键因素之一。 活动用户的数量还决定了托管各种服务（需要跨服务器启用社交方案）的构成。
尽管我们的测试使用典型的数据集并应用您在实际客户部署中可能出现的负载复杂性，每个部署都是独一无二的。 您的容量规划工作应考虑预期的使用特征、功能配置和硬件资源可用性。 有些因素可能具有一定影响或大大改变容量数量，包括：
增加的电子邮件使用量模式可能增加 Outlook Social Connector 生成的负载。
例如， (写入操作百分比的显著增加，标记的增加或 @mention) 事务组合可能会增加数据库服务器上的负载。
可以添加或删除 Web 服务器，以平衡 Web 服务器、SQL Server和分布式缓存节点之间的 CPU 负载。
请仔细遵循标准 SharePoint Server 2013 配置指南，以获得最佳性能。 对社交事务有重要影响的考虑事项如下：
配置文件 DB 的单独物理磁盘 - 由于社交事务在 Profile DB 上可能具有大量磁盘使用量，因此建议将配置文件 DB 保留在运行SQL Server的服务器上的自己的一组物理磁盘上。
用户配置文件服务应用程序的内存要求 - 用户配置文件服务应用程序位于前端 Web 服务器上，严重依赖其内存中缓存。 确保前端 Web 服务器具有足够的 RAM 以缓存大量数据请求。 最小建议 RAM 为每个前端 Web 服务器 12 GB。
分布式缓存服务器的内存要求 - 社交功能（尤其是微博）主要依赖于充足和强大的分布式缓存。 这些计算机上的内存太低可能会使 SharePoint 服务器场的容量下降，此缓存将重新填充。 因此，我们建议您将承载分布式缓存的服务器配置为使用至少 12 GB RAM，并根据部署中的用户总数量，根据需要进行横向扩展。
SharePoint Server 2013 社交部署强制要求为每个想要使用社交功能的用户预配个人网站。 在内容数据库的级别规划个人网站集的创建增长。 有关如何扩展个人网站集的详细信息，请参阅 Software boundaries and limits for SharePoint 2013。