SharePoint Server 2013 的性能测试
适用于：
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
本文介绍了如何测试 SharePoint Server 2013 的性能。 测试和优化阶段是有效容量管理的关键部分。 应在将新体系结构部署到生产环境之前对其进行测试，并遵循监视最佳做法进行验收测试，以确保设计的体系结构达到性能和容量目标。 这使您可以在潜在瓶颈在实时部署中影响用户之前识别和优化它们。 如果要从 Office SharePoint Server 2007 环境升级并计划进行体系结构更改，或者正在估算新 SharePoint Server 2013 功能的用户负载，则测试非常重要，以确保新的基于 SharePoint Server 2013 的环境满足性能和容量目标。
测试环境后，可以分析测试结果以确定需要做出哪些更改才能实现在步骤 1：SharePoint Server 2013 的容量规划模型中建立的性能和容量目标。
以下是预生产时应遵循的推荐子步骤：
模仿您在步骤 2：设计中设计的初始体系结构创建测试环境。
使用您在步骤 1：模型中识别的数据集或部分数据集填充存储。
使用代表您在步骤 1：模型中识别的工作负荷的综合负荷来为系统增加压力。
运行测试、分析结果并优化您的体系结构。
将已优化的体系结构部署到数据中心，然后推出具有较小用户组的试验。
分析试验结果、标识潜在瓶颈，并优化体系结构。 如果需要，请重新测试。
部署到生产环境。
阅读本文之前，您应该阅读 SharePoint Server 2013 的容量管理和调整大小概述。
创建测试计划
验证您的计划是否包括：
设计为在预期生产性能目标上执行操作的硬件。 请始终保守地度量测试系统的性能。
如果你有自定义代码或自定义组件，请务必先单独测试这些组件的性能，以验证其性能和稳定性。 稳定后，应测试安装了这些组件的系统，并将性能与未安装它们的场进行比较。 自定义组件通常是生产系统中性能和可靠性问题的主要原因。
知道测试的目标。 提前了解测试目标是什么。 是为了验证为服务器场开发的新自定义组件的性能吗？ 是为了了解为一组内容爬网和创建索引所用的时间吗？ 是为了确定您的服务器场每秒可以支持多少请求吗？ 在一个测试期间可以存在许多不同的目标，制定良好测试计划的第一步就是决定您的目标。
了解如何为您的测试目标进行度量。 例如，如果有兴趣测量场的吞吐量容量，则需要测量 RPS 和页面延迟。 如果要测量搜索性能，则需要测量爬网时间和文档索引速率。 如果您的测试目标容易理解，它将帮助您清楚地定义需要验证哪些关键绩效指标以完成您的测试。
创建测试环境
在决定测试目标、定义您的度量以及确定用于服务器场的容量要求（通过该过程的步骤 1 和步骤 2）之后，下个目标是设计和创建测试环境。 创建测试环境的工作经常被低估。 它应该尽可能地复制生产环境。 设计测试环境时应该考虑的一些功能包括：
身份验证：确定场是否将使用 Active Directory 域服务 (AD DS) 、基于表单的身份验证 (，如果是，则使用哪些目录) 、基于声明的身份验证等。无论使用哪个目录，测试环境中需要多少用户，以及如何创建这些用户？ 需要多少个组或角色，如何创建和填充它们？ 还需要确保为身份验证服务分配了足够的资源，以免在测试期间成为瓶颈。
DNS：了解测试期间需要哪些命名空间。 确定哪些服务器将响应这些请求，并确保你已包括一个计划，其中包含哪些服务器将使用哪些 IP 地址，以及需要创建哪些 DNS 条目。
负载均衡：假设你使用多个服务器 (通常会或可能没有足够的负载来保证) 进行负载测试，则需要某种负载均衡器解决方案。 这可能是硬件负载平衡设备，或者可以使用软件负载平衡，例如 Windows NLB。 确定要使用的内容，并记下快速高效地设置它所需的所有配置信息。 另一个需要记住的是，负载测试代理通常每 30 分钟尝试将地址解析为 URL 一次。 这意味着不应使用本地主机文件或轮循机制 DNS 进行负载均衡，因为测试代理最终可能会针对每个单个请求转到同一服务器，而不是在所有可用服务器之间均衡。
测试服务器：规划测试环境时，不仅需要规划用于 SharePoint Server 2013 服务器场的服务器，还需要规划执行测试所需的计算机。 通常，这至少包括三台服务器;可能需要更多。 如果使用 Visual Studio Team System (Team Test Load Agent) 进行测试，则一台计算机将用作负载测试控制器。 通常有两台或更多台计算机用作负载测试代理。 代理是从测试控制器接受关于测试对象的指令并向 SharePoint Server 2013 服务器场发送请求的计算机。 测试结果自身将存储在基于 SQL Server 的计算机上。 不应使用用于 SharePoint Server 2016 场的同一台基于 SQL Server 的计算机，因为编写测试数据会使 SharePoint Server 2013 场的可用 SQL Server 资源倾斜。 还需要在运行测试时监控测试服务器以确保测试结果对于您设置的服务器场具有代表性，监控方法与在 SharePoint Server 2013 服务器场或域控制器等位置监控服务器时相同。 有时，负载代理或控制器自身会成为瓶颈。 如果发生这种情况，则在测试中看到的吞吐量通常不是服务器场可以支持的最大吞吐量。
SQL Server：在测试环境中，请按照存储和 SQL Server 容量规划和配置一文中的“配置 SQL Server”和“验证和监视存储和 SQL Server 性能”部分的指导 进行操作， (SharePoint Server) 。
数据集验证：在决定要针对哪些内容运行测试时，请记住，在最佳情况下，将使用来自现有生产系统的数据。 例如，您可以从生产服务器场备份内容数据库，并将其存储到测试环境中，然后附加数据库以将内容导入服务器场。 在对虚拟或示例数据运行测试时，始终存在由内容集中的差异导致结果扭曲的风险。
如果必须创建示例数据，请在构建该内容时牢记以下几点注意事项：
应该发布所有页面；不应检出任何内容
导航应该真实；您所构建的导航不能多于在生产中合理预期使用的导航。
应该清楚了解生产网站将使用的自定义设置。 例如，应该在测试环境中以尽可能接近生产环境的方式实现母版页、样式表和 JavaScript 等。
确定需要多少个 SharePoint 组和/或权限级别，以及如何将用户与其关联。
弄清楚是否需要进行配置文件导入及其所用时间。
确定是否需要访问群体，以及如何创建和填充它们。
确定是否需要更多搜索内容源，以及创建它们所需的内容。 如果不需要创建它们，请确定是否具有用于对其进行爬网的网络访问权限。
确定是否有足够的示例数据 - 文档、列表、列表项等。如果没有，请为创建此内容的方式创建计划。
请规划足够的独特内容以充分测试搜索。 一个常见问题是将相同文档数百次甚至数千次地上传到具有不同名称的不同文档库。 因为查询处理器将花费等量时间来进行重复检测，而它在生产环境中不会为真实内容进行重复检测，所以这可能会影响搜索性能。
创建测试和工具
测试环境正常运行后，可以创建和微调将用于测量服务器场性能容量的测试。 有时，该部分会特别参考 Visual Studio Team System（团队测试负载代理），但许多概念都可以应用，而不考虑您使用哪种负载测试工具。 有关 Azure DevOps (以前的 VSTS) 可用的测试工具的详细信息，请参阅 Azure DevOps 的 DevOps 工具概述。
还可以将 SharePoint 负载测试工具包 (LTK) 与 VSTS 配合使用，对 SharePoint 2010 场进行负载测试。 负载测试工具包可以基于 Windows SharePoint Services 3.0 和 Microsoft Office SharePoint Server 2007 IIS 日志生成 Visual Studio Team System 2008 负载测试。 VSTS 负载测试可用于生成针对 SharePoint Foundation 2010 或 SharePoint Server 2010 的综合负载，作为容量规划练习或预升级压力测试的一部分。
负载测试工具包包含在 Microsoft SharePoint 2010 管理工具包 v2.0 中，可从 Microsoft 下载中心获取。
测试成功的关键条件是能够通过生成对各种测试网站数据的请求（与用户访问生产 SharePoint Server 2013 服务器场中的各种内容一样）来有效模拟真实的工作负荷。 为此，通常需要构造测试，使其由数据驱动。 您应该使用几个采用包含 URL 的数据源的测试，以便这些项可以动态访问该组页面，而不是创建上百个单独的硬编码测试来访问特定页面。
在 Visual Studio Team System (Team Test Load Agent) 中，数据源可以采用各种格式，但 CSV 文件格式通常最容易在开发和测试环境之间管理和传输。 请记住，使用该内容创建 CSV 文件可能要求创建自定义工具以枚举各种 URL 使用的基于 SharePoint Server 2013 的环境和记录。
您可能需要使用用于以下任务的工具：
在 Active Directory 或其他身份验证存储（如果您使用的是基于表单的身份验证）中创建用户和组
枚举用于网站、列表和库、列表项、文档等的 URL，并将其放入 CSV 文件以进行负载测试
将示例文档上载到各种文档库和网站
创建网站集、Web、列表、库、文件夹和列表项
创建"我的网站"
使用测试用户的用户名和密码创建 CSV 文件；这些是将对其执行负载测试的用户帐户。 应该存在用于不同用户的多个文件，例如，某些文件仅包含管理员用户，某些包含具有提升权限的其他用户（例如作者/参与者、层次结构管理员等等），而其他文件仅包含读者，以此类推。
创建示例搜索关键字和阶段的列表
如果使用基于表单的身份验证) ，请使用用户和 Active Directory 组 (或角色填充 SharePoint 组和权限级别
创建 Web 测试时，您应该观察和实现其他最佳实践。 它们包括：
将简单的 Web 测试记录为起点。 这些测试将包含用于 URL、ID 等参数的硬编码值。将这些硬编码值替换为 CSV 文件中的链接。 在 Visual Studio Team System (Team Test Load Agent) 中绑定这些值很容易。
请始终具有用于您的测试的验证规则。 例如，请求页面时，如果发生错误，通常会获得响应error.aspx页。 从 Web 测试的角度来看，它看起来只是另一个正面响应，因为负载测试结果中成功) (HTTP 状态代码为 200。 但是，显然发生了错误，所以应该使用不同方式跟踪它。 创建一个或多个验证规则使您可以在发送特定响应文本时将其捕获以使验证失败，并且该请求将标记为失败。 例如，在 Visual Studio Team System (Team Test Load Agent) 简单的验证规则可能是 ResponseUrl 验证 - 如果重定向后呈现的页面不是测试中记录的相同响应页，则它会记录失败。 还可以添加 FindText 规则，以便在响应中发现“拒绝访问”一词时记录失败。
使用具有不同角色的多个用户进行测试。 特定行为（例如输出缓存）将存在差异，具体取决于当前用户的权限。 例如，网站集管理员或具有审批或创作权限的经过身份验证的用户不会获得缓存结果，因为我们始终希望他们看到最新版本的内容。 然而，匿名用户将获得缓存的内容。 您需要确保测试用户具有与生产环境的混合用户大致匹配的混合的角色。 例如，在生产环境中，可能只有两个或三个网站集管理员，因此不应创建测试，其中 10% 的页面请求是由网站集管理员对测试内容的用户帐户发出的。
依赖分析的请求是 Visual Studio Team System（团队测试负载代理）的属性，它可以确定测试代理是否仅应尝试检索页面，还是应检索页面和作为页面一部分的所有相关请求，例如图像、样式表、脚本等。进行负载测试时，我们通常出于以下几个原因忽略这些项：
在用户首次点击网站后，本地浏览器通常会对这些项进行缓存
通常，这些项不来自基于 SharePoint Server 2013 的环境中的 SQL Server。 启用 BLOB 缓存后，Web 服务器会改为为它们提供服务，因此它们不会生成 SQL Server 负载。
如果您经常具有高百分比的首次点击网站的用户，或者您已禁用浏览器缓存，又或者由于某个原因您不希望使用 BLOB 缓存，那么在您的测试中启用依赖分析的请求可能很有意义。 然而，这的确是例外，而不是用于大部分实现的经验法则。 请注意，如果您启用它，它可以大大增加测试控制器报告的 RPS 数量。 这些请求的处理速度如此之快，可能会误导你认为服务器场中的可用容量比实际容量多。
请记住为客户端应用程序活动建模。 客户端应用程序（如 Microsoft Word、PowerPoint、Excel 和 Outlook）也会生成对 SharePoint Server 2013 场的请求。 它们通过发送服务器请求（例如检索 RSS 源、获取社交信息、请求网站和列表结构的详细信息、同步数据等）来增加环境负载。如果实现中具有这些客户端，则应包括这些类型的请求并建模。
大部分情况下，Web 测试应该仅包含单个请求。 如果测试仅包含单个请求，将更容易为您的测试利用方式和各个请求进行微调和疑难解答。 如果 Web 测试模拟的操作由多个请求组成，则通常需要包含多个请求。 例如，若要测试这组操作，需要一个包含多个步骤的测试：签出文档、编辑文档、签入文档和发布文档。 它还需要步骤之间的保留状态；例如，将其检出、编辑和检入时应该使用相同的用户帐户。 在单个 Web 测试中，对于需要在每个步骤之间延续状态的多步骤操作，最好使用多个请求来提供服务。
单独进行每个 Web 测试。 请先确保每个测试都可以成功完成，然后再到较大的负载测试中运行它。 请确定是否可以解析用于 Web 应用程序的所有名称，以及测试中使用的用户帐户具有足够权限来执行测试。
Web 测试包括对单个页面、上传文档、查看列表项等的请求。所有这些都在负载测试中汇总在一起。 负载测试是插入要执行的所有不同 Web 测试的位置。 可以为每个 Web 测试提供将执行的时间百分比，例如，如果发现生产场中 10% 的请求是搜索查询，则在负载测试中，会将查询 Web 测试配置为运行 10% 的时间。 在 Visual Studio Team System (Team Test Load Agent) 中，负载测试也是配置浏览器组合、网络组合、加载模式和运行设置等内容的方式。
以下是应该为负载测试观察和实现的额外最佳实践：
在测试中使用合理的读/写比率。 测试中的写入数量过载可以大大影响测试的整体吞吐量。 即使在协作服务器上，读/写比率也具有读取多于写入的倾向。
考虑其他占用大量资源的操作带来的影响，并决定它们是否应该在负载测试期间发生。 例如，通常不会在负载测试期间进行备份和还原等操作。 完全搜索爬网通常可能不会在负载测试期间运行，而增量爬网可能可以正常运行。 您需要考虑如何在生产中计划这些任务；是否会在高峰负载时间运行它们呢？ 如果不是，则在负载测试期间，当你尝试确定可以支持峰值流量的最大稳定状态负载时，它们可能会被排除。
不要使用思考时间。 思考时间是 Visual Studio Team System（团队测试负载代理）的一项功能，它使您可以模拟用户在单击页面时暂停的时间。 例如，典型的用户可能会加载页面、花三分钟阅读它，然后单击页面上的链接以访问另一个网站。 几乎不可能在测试环境中尝试对其正确有效地创建模型，并且这不会为测试结果增加价值。 难于创建模型的原因是大部分组织不可以监控不同的用户及其在不同类型的 SharePoint 网站（例如发布、搜索和协作等网站的对比）上单击时的间隔时间。 它也不会真正增加价值，因为即使用户可能会在页面请求之间暂停，基于 SharePoint Server 2013 的服务器也不会。 它们只会获得一个稳定的请求流，这些请求可能会随时间推移而出现高峰和谷值，但不会因为每个用户在单击页面上的链接之间暂停而无所事事地等待。
了解用户和请求之间的差异。 Visual Studio Team System (Team Test Load Agent) 具有负载模式，其中要求输入要模拟的用户数。 这与应用程序用户无关，只是负载测试代理上用于生成请求的线程数。 例如，一个常见的错误是认为，如果部署将有 5,000 个用户，那么 5,000 个是应在 Visual Studio Team System (Team Test Load Agent) 中使用的数字 - 它不是！ 这是在估算容量规划要求时，使用要求应基于每秒请求数而不是用户数的众多原因之一。 在 Visual Studio Team System (Team Test Load Agent) 负载测试中，你会发现，通常每秒只需使用 50 到 75 个负载测试“用户”即可生成数百个请求。
对最可靠和最可重现的测试结果使用不变的负载模式。 在 Visual Studio Team System (Team Test Load Agent) 中，可以选择基于固定数量的用户 (线程进行负载，如上一点) 中所述，用户增加负载模式或基于目标的使用情况测试中所述。 分级负载模式是指开始时具有较小用户数量，然后每分钟逐渐添加额外的用户。 基于目标的使用测试是指为特定诊断计数器（例如 CPU 使用率）建立阈值，然后测试驱动负载的尝试，以便将此计数器保持在为其定义的最小和最大阈值之间。 但是，如果您只是尝试确定 SharePoint Server 2013 场在峰值负载期间可以维持的最大吞吐量，则仅选择恒定负载模式会更有效且更准确。 这使您可以更轻松地标识在开始定期超出应该在运行状况良好的服务器场中保持的阈值之前，系统可以承受的负载。
每次运行负载测试时，请记住它会更改数据库中的数据。 无论是上载文档、编辑列表项或仅仅在使用数据库中记录活动，都会将数据写入 SQL Server。 若要确保从每次负载测试中获得一组一致的合法测试结果，您应该在运行第一次负载测试前提供备份。 每次负载测试完成后，应使用备份将内容还原到开始测试之前的方式。
另请参阅
概念
SharePoint Server 2016 的软件边界和限制
其他资源
Capacity management and sizing overview for SharePoint Server 2013