通过

SharePoint Server 2013 的性能测试

  • 项目

 

**上一次修改主题：**2017-08-25

**摘要：**了解如何规划和执行 SharePoint Server 2013 环境的性能测试。

本文介绍如何测试SharePoint Server 2013的性能。测试和优化舞台是有效的容量管理的一个重要组成部分。将它们部署到生产环境，并应执行验收测试结合下列监视的最佳做法，以确保设计的体系结构实现的性能和容量的目标之前，应该测试新的体系结构。这允许您确定并优化潜在的瓶颈，让它们不会影响实际的部署中的用户。如果您要升级从Office SharePoint Server 2007环境和计划如何进行体系结构更改，或估计用户负载的新的SharePoint Server 2013功能，然后测试尤为重要，以确保您新的SharePoint Server 2013-基于的环境能够满足性能和容量的目标。

测试您的环境后，可以分析测试结果以确定需要进行哪些更改来达到您在SharePoint Server 2013 的容量规划的步骤 1：模型中建立的性能和容量目标。

建议您在生产前遵循以下子步骤：

  • 模仿您在步骤 2：设计中设计的初始体系结构创建测试环境。

  • 使用您在步骤 1：模型中识别的数据集或部分数据集填充存储。

  • 使用代表您在步骤 1：模型中识别的工作负荷的综合负荷来为系统增加压力。

  • 运行测试、分析结果并优化您的体系结构。

  • 将已优化的体系结构部署到数据中心，然后推出具有较小用户组的试验。

  • 分析试验结果、标识潜在瓶颈，并优化体系结构。如果需要，请重新测试。

  • 部署到生产环境。

阅读本文之前，您应该阅读 SharePoint Server 2013 的容量管理和调整大小概述。

本文内容：

  • 创建测试计划

  • 创建测试环境

  • 创建测试和工具

创建测试计划

验证您的计划是否包括：

  • 设计为在预期生产性能目标上执行操作的硬件。请始终保守地度量测试系统的性能。

  • 如果您具有自定义代码或自定义组件，请先单独测试这些组件的性能以验证其性能和稳定性，这十分重要。在它们稳定之后，您应该测试安装了这些组件的系统，并将其性能与没有安装它们的服务器场进行对比。自定义组件通常是生产系统中性能和可靠性问题的主要原因。

  • 知道测试的目标。提前了解测试目标是什么。是为了验证为服务器场开发的新自定义组件的性能吗？是为了了解为一组内容爬网和创建索引所用的时间吗？是为了确定您的服务器场每秒可以支持多少请求吗？在一个测试期间可以存在许多不同的目标，制定良好测试计划的第一步就是决定您的目标。

  • 了解如何为您的测试目标进行度量。例如，如果您对度量服务器场的吞吐量容量感兴趣，您会希望度量 RPS 和页面延迟。如果您度量的是搜索性能，您会希望度量爬网时间和文档索引率。如果您的测试目标容易理解，它将帮助您清楚地定义需要验证哪些关键绩效指标以完成您的测试。

创建测试环境

在决定测试目标、定义您的度量以及确定用于服务器场的容量要求（通过该过程的步骤 1 和步骤 2）之后，下个目标是设计和创建测试环境。创建测试环境的工作经常被低估。它应该尽可能地复制生产环境。设计测试环境时应该考虑的一些功能包括：

  • **身份验证：**确定服务器场是否使用 Active Directory 域服务 (AD DS)、基于表单的身份验证（如果使用它，要使用哪个目录）、基于声明的身份验证等等。无论您使用哪个目录，都需要考虑测试环境中需要多少用户，以及您将如何创建它们？需要多少组或角色，以及如何创建和填充它们？您还需要确保为身份验证服务分配足够的资源，以防止它们在测试期间成为瓶颈。

  • **DNS：**了解测试期间所需的命名空间。标识将响应这些请求的服务器，并确保已包含关于哪些服务器将使用哪些 IP 地址以及需要创建哪些 DNS 条目的规划。

  • **负载平衡：**假定您使用多个服务器（您通常会这样操作，否则可能没有足够负载来保证负载测试），您将需要某种负载平衡器解决方案。这可能是硬件负载平衡设备，或者可以使用软件负载平衡，例如 Windows NLB。请找出要使用哪种解决方案，并写下快速有效地设置该方案所需的所有配置信息。还需要记住，负载测试代理通常每 30 分钟仅进行一次将地址解析为 URL 的尝试。这意味着不应该将本地主机文件或循环 DNS.用于负载平衡，因为测试代理可能会最终使用相同服务器处理每个请求，而不是在所有可用服务器之间进行平衡。

  • 测试服务器： 当您计划您的测试环境时，不仅需要规划SharePoint Server 2013服务器场的服务器，则还需要计划执行测试所需的计算机。通常，将包括 3 个服务器最少;更有必要。如果使用的 Visual Studio Team System （团队测试加载代理） 进行测试，一台机器将用作负载测试控制器。通常有 2 个或更多用作负载测试代理的计算机。代理是采取从有关如何测试和SharePoint Server 2013场到发出请求的测试控制器的说明进行操作的计算机。基于 SQL Server 的计算机上存储自己的测试结果。因为将检测数据写入将扭曲SharePoint Server 2013服务器场可用的 SQL Server 资源，您不应使用SharePoint Server 2016场，使用同一个基于 SQL Server 的计算机。您还需要监视您的测试服务器，运行您的测试中，相同的方式将监视SharePoint Server 2013场，或域控制器、 等，以确保测试结果所代表您设置该服务器场中的服务器时。有时负载代理或控制器可能成为瓶颈本身。如果发生这种情况再看测试中的吞吐量通常不是场可以支持的最大值。

  • **SQL Server：**在您的测试环境中，请遵循文章存储和 SQL Server 容量规划与配置 (SharePoint Server)的"配置 SQL Server"和"验证和监控存储和 SQL Server 性能"部分中的指南。

  • **数据集验证：**在决定要对哪些内容运行测试时，请记住在最佳方案中，您将使用来自现有的生产系统的数据。例如，您可以从生产服务器场备份内容数据库，并将其存储到测试环境中，然后附加数据库以将内容导入服务器场。在对虚拟或示例数据运行测试时，始终存在由内容集中的差异导致结果扭曲的风险。

如果必须创建示例数据，请在构建该内容时牢记以下几点注意事项：

  • 应该发布所有页面；不应检出任何内容

  • 导航应该真实；您所构建的导航不能多于在生产中合理预期使用的导航。

  • 应该清楚了解生产网站将使用的自定义设置。例如，应该在测试环境中以尽可能接近生产环境的方式实现母版页、样式表和 JavaScript 等。

  • 确定将需要多少 SharePoint 组和/或权限级别，以及如何将用户与其相关联。

  • 弄清楚是否需要进行配置文件导入及其所用时间。

  • 确定是否需要访问群体，以及如何创建和填充它们。

  • 确定是否需要额外搜索内容源，以及需要使用什么来创建它们。如果不需要创建它们，请确定是否具有用于对其进行爬网的网络访问权限。

  • 确定是否具有足够示例数据，即文档、列表、列表项等等。如果没有，请创建关于如何创建该内容的规划。

  • 请规划足够的独特内容以充分测试搜索。一个常见问题是将相同文档数百次甚至数千次地上传到具有不同名称的不同文档库。因为查询处理器将花费等量时间来进行重复检测，而它在生产环境中不会为真实内容进行重复检测，所以这可能会影响搜索性能。

创建测试和工具

功能测试环境后，就可以创建和微调将用于测量性能容量的服务器场的测试。本部分有时会使引用专门到 Visual Studio Team System （团队测试加载代理），但许多概念是适用而不考虑所使用的负载测试工具。有关 Visual Studio 团队系统的详细信息，请参阅 msdn (https://msdn.microsoft.com/en-us/library/fda2bad5.aspx)" Visual Studio Team System 。

您还可以将 SharePoint 负载测试工具包 (LTK) 和用于 SharePoint 2010 服务器场的负载测试的 VSTS 联合使用。负载测试工具包可以基于 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 Administration Toolkit v1.0 中包含负载测试工具包，可以从 Microsoft 下载中心 (https://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en) 中使用它。

成功的测试一个关键条件是内容的能够有效地通过跨范围广泛的测试网站数据，生成请求模拟实际工作负荷，用户会访问广泛的生产SharePoint Server 2013服务器场中一样。为此，通常需要构建您的测试，它们是数据驱动的。而不是创建数百个硬编码可访问特定页面的单个测试，您应该使用几个使用包含这些项的 Url 的数据源动态访问页该集的测试。

在 Visual Studio 团队系统 （团队测试负载代理） 中，数据源可能采用不同的格式，但 CSV 文件的格式通常是最简单的方式管理和开发和测试环境之间传输。请记住与该内容创建 CSV 文件可能需要创建自定义工具来枚举SharePoint Server 2013-基于环境和记录正在使用的各个 Url。

您可能需要使用用于以下任务的工具：

  • 在 Active Directory 或其他身份验证存储（如果您使用的是基于表单的身份验证）中创建用户和组

  • 枚举用于网站、列表和库、列表项、文档等的 URL，并将其放入 CSV 文件以进行负载测试

  • 将示例文档上载到各种文档库和网站

  • 创建网站集、Web、列表、库、文件夹和列表项

  • 创建"我的网站"

  • 使用测试用户的用户名和密码创建 CSV 文件；这些是将对其执行负载测试的用户帐户。应该存在用于不同用户的多个文件，例如，某些文件仅包含管理员用户，某些包含具有提升权限的其他用户（例如作者/参与者、层次结构管理员等等），而其他文件仅包含读者，以此类推。

  • 创建示例搜索关键字和阶段的列表

  • 使用用户和 Active Directory 组（如果您使用的是基于表单的身份验证，则使用角色）来填充 SharePoint 组和权限级别。

创建 Web 测试时，您应该观察和实现其他最佳实践。它们包括：

  • 将简单的 Web 测试记录为起始点。这些测试具有用于 URL、ID 等参数的硬编码的值。使用来自 CSV 文件的链接替代这些硬编码的值。在 Visual Studio Team System（团队测试负载代理）中对这些值进行数据绑定非常简单。

  • 请始终具有用于您的测试的验证规则。例如，请求页面时，如果发生错误，您通常会得到响应的 error.aspx 页面。从 Web 测试角度而言，它与另一个正面响应的效果相同，因为您在负载测试结果中获得的 HTTP 状态代码为 200（成功）。但是，显然发生了错误，所以应该使用不同方式跟踪它。创建一个或多个验证规则使您可以在发送特定响应文本时将其捕获以使验证失败，并且该请求将标记为失败。例如，在 Visual Studio Team System（团队测试负载代理）中，简单的验证规则可以为 ResponseUrl 验证；如果在重定向后所呈现的页面不同于测试中记录的响应页面，该验证将记录失败。您还应该添加 FindText 规则；例如，如果它在响应中找到"拒绝访问" 一词，它将记录失败。

  • 使用具有不同角色的多个用户进行测试。特定行为（例如输出缓存）将存在差异，具体取决于当前用户的权限。例如网站集管理员或者具有审批或创作权限的经过身份验证的用户不会获得缓存的结果，因为我们希望他们始终看到最新版本的内容。然而，匿名用户将获得缓存的内容。您需要确保测试用户具有与生产环境的混合用户大致匹配的混合的角色。例如，在生产中可能仅有两个或三个网站集管理员，所以您在创建测试时，不应该使用网站集管理员用户帐户在整个测试内容中发出 10% 的页面请求。

  • 依赖分析的请求是 Visual Studio Team System（团队测试负载代理）的属性，它可以确定测试代理是否仅应尝试检索页面，还是应检索页面和作为页面一部分的所有相关请求，例如图像、样式表、脚本等。进行负载测试时，我们通常出于以下几个原因忽略这些项：

    • 在用户首次点击网站后，本地浏览器通常会对这些项进行缓存

    • 这些项目不通常来自 SQL Server 在SharePoint Server 2013-基于环境。打开 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（团队测试负载代理）中，负载测试还与您配置浏览器组合、网络组合、负载模式和运行设置的方式相关。

以下是应该为负载测试观察和实现的额外最佳实践：

  • 在测试中使用合理的读/写比率。测试中的写入数量过载可以大大影响测试的整体吞吐量。即使在协作服务器上，读/写比率也具有读取多于写入的倾向。

  • 考虑其他占用大量资源的操作带来的影响，并决定它们是否应该在负载测试期间发生。例如，通常不会在负载测试期间进行备份和还原等操作。完全搜索爬网通常可能不会在负载测试期间运行，而增量爬网可能可以正常运行。您需要考虑如何在生产中计划这些任务；是否会在高峰负载时间运行它们呢？如果不是，可能不应该在负载测试中包含它们，因为在测试时您要尝试确定可以为高峰流量支持的稳定状态下的最大负载。

  • 不使用思考时间。思考时间是一个功能的 Visual Studio Team System （团队测试负载代理程序），您可以模拟用户在页面上单击之间暂停的时间。例如典型的用户可能会加载的页面，花三分钟时间阅读它，然后单击页后，可以访问另一个站点上的链接。试图在测试环境中模拟这是几乎不可能达到目的，而实际上并不将值添加到测试结果。由于多数企业没有一种方法来监视不同的用户和不同类型的 SharePoint 网站 （如发布和搜索和协作，等等。） 单击它们之间所花的时间很难给模型。它还并不真正增值因为即使用户可能会暂停页请求， SharePoint Server 2013之间-基于的服务器不这样做。他们只是得到稳定的可能随着时间的推移有高峰和低谷的请求流，但不是等待空闲状态为每个用户暂停之间单击页上的链接。

  • 了解用户和请求之间的差异。Visual Studio Team System（团队测试负载代理）具有负载模式，它将要求您输入要模拟的用户数量。这与应用程序用户毫无关系，它实际上是要在负载测试代理上用于生成请求的线程数。一个常见错误是认为如果部署具有 5000（示例数量）用户，那么 5000 就是应该在 Visual Studio Team System（团队测试负载代理）中使用的数量。并非如此！这就是在估计容量规划要求时，使用要求应该基于每秒请求数量而不是用户数量的原因之一。在 Visual Studio Team System（团队测试负载代理）负载测试中，您会发现经常可以仅使用 50 到 75 位负载测试"用户"来生成每秒数百个请求。

  • 常量负载模式用于最可靠和可重复的测试结果。在 Visual Studio Team System （团队测试加载代理） 可以作为基础的选项加载上固定数目的用户 （线程，作为前一个点所述），分向上负载模式的用户，或基于使用情况的测试目标。步骤的负载模式时，较低的用户数字开头，再"逐步提高"将其他用户添加每隔几分钟。基于目标使用测试时，可以建立某些诊断计数器，如 CPU 利用率的阈值，并测试尝试驱动负载，需要为其定义的最小值和最大阈值之间该计数器。但是，如果只要确定最大吞吐量SharePoint Server 2013场可以维持在高峰负载期间，它是更有效且准确的只需选择一个常量负载模式。使您可以更轻松地识别系统可以花开始定期超过应保持在正常的服务器场中的阈值之前的负载量。

每次运行负载测试时，请记住它会更改数据库中的数据。无论是上载文档、编辑列表项或仅仅在使用数据库中记录活动，都会将数据写入 SQL Server。若要确保从每次负载测试中获得一组一致的合法测试结果，您应该在运行第一次负载测试前提供备份。在完成每次负载测试之后，应该使用备份将内容还原到测试开始之前的状态。

See also

SharePoint Server 2013 的容量规划
监视和维护 SharePoint Server 2013
SharePoint Server 2016 中的监视和报告功能
SharePoint Server 2016 的软件边界和限制

SharePoint Server 2013 的容量管理和调整大小概述