SharePoint Server 2010 的性能测试

  • 项目

 

适用于： SharePoint Server 2010

上一次修改主题： 2016-11-30

本文介绍如何测试 Microsoft SharePoint Server 2010 的性能。测试和优化阶段是进行有效容量管理的关键阶段。您应该先测试新体系结构，然后再将其部署到生产中，并且应该在进行验收测试的同时监视最佳做法，以确保您所设计的体系结构能够达到性能和容量目标。这样，才能确定并优化潜在瓶颈，以防它们在实时部署中影响用户。如果是从 Microsoft Office SharePoint Server 2007 环境升级，并打算进行体系结构更改，或者要估计新 SharePoint Server 2010 功能的用户负载，则测试特别重要，可确保基于 SharePoint Server 2010 的新环境满足性能和容量目标。

在测试环境之后，可以分析测试结果，以确定需要做出哪些更改，才能达到您在 SharePoint Server 2010 的容量规划的步骤 1：模型中制订的性能和容量目标。

下面是建议的应该遵循的一些生产前子步骤：

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

  • 使用在步骤 1：模型中确定的数据集或数据集的一部分填充存储空间。

  • 以表示在步骤 1：模型中确定的工作量的综合负载对系统施加压力。

  • 运行测试，分析结果，然后优化体系结构。

  • 在数据中心部署已优化的体系结构，然后对一小组用户试运行。

  • 分析试点结果，确定潜在瓶颈，然后优化该体系结构。根据需要重新测试。

  • 部署到生产环境中。

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

本文内容：

  • 创建测试计划

  • 创建测试环境

  • 创建测试和工具

创建测试计划

验证您的计划是否包含以下项：

  • 设计为按预期生产性能目标运行的硬件。始终以保守方式测量测试系统的性能。

  • 如果有自定义代码或自定义组件，请务必先隔离测试这些组件的性能，以验证它们的性能和稳定性。在确定组件稳定后，应测试安装了这些组件的系统，并比较其性能与没有安装这些组件的服务器场的性能。自定义组件通常是生产系统中性能和可靠性问题的罪魁祸首。

  • 了解测试目标。提早了解测试目标是什么。是否要验证为服务器场开发的一些新自定义组件的性能？是否要查看对一组内容进行爬网和索引所需的时间？是否要确定您的服务器场支持的每秒请求数？在测试过程中可能有多个不同的目标，开发优良的测试计划的第一步就是确定您的目标。

  • 了解如何通过指标来衡量测试目标。例如，如果有兴趣测量服务器场的吞吐量容量，则需要测量 RPS 和页面延迟。如果要测量搜索性能，则需要测量爬网时间和文档索引率。如果清楚了解测试目标，则有助于您明确定义为完成测试而需要验证的关键绩效指标。

创建测试环境

确定测试目标后，应定义测量内容，并确定服务器场的容量要求（在本过程的步骤 1 和步骤 2 中），下一个目标就是设计和创建测试环境。用户通常会低估创建测试环境的工作。该工作应该尽可能接近地复制生产环境。在设计测试环境时应该考虑的一些功能包括：

  • 身份验证 – 确定服务器场是否使用 Active Directory 域服务 (AD DS)、基于表单的身份验证（如果要使用该身份验证，应确定具体目录）、基于声明的身份验证等。不管使用哪个目录，都需确定该测试环境中需要多少名用户，以及如何创建他们？将需要多少个组或角色，以及如何创建和填充它们？还需要确保有足够的资源分配给身份验证服务，而它们在测试中不会成为瓶颈。

  • DNS – 了解测试过程中将需要哪些命名空间。确定哪些服务器会响应这些请求，并确保您已提供相关计划，其中包括哪些服务器将使用哪些 IP 地址，以及需要创建哪些 DNS 条目。

  • 负载平衡 – 假设使用多台服务器（在这种情况下，您通常能够获得（也可能无法获得）足够的负载来保证负载测试），则需要使用某种类型的负载平衡器解决方案。可能是硬件负载平衡设备，也可以使用软件负载平衡，如 Windows NLB。先决定要使用的解决方案，然后记下快速有效地设置该解决方案所需的所有配置信息。还要记住：负载测试代理通常仅每隔 30 分钟尝试解析一次 URL 的地址。这表示不能对负载平衡使用本地主机文件或循环 DNS，因为测试代理可能会在每一次请求时以转到同一台服务器结束，而不是在所有可用服务器之间平衡负载。

  • 测试服务器 – 在规划测试环境时，不仅需要规划用于 SharePoint Server 2010 服务器场的服务器，而且需要规划执行测试所需的计算机。通常，测试计算机将至少包括 3 台服务器；可能有必要包括更多服务器。如果使用 Visual Studio Team System (Team Test Load Agent) 进行测试，则需将一台计算机用作负载测试控制器。通常有 2 台或更多计算机用作负载测试代理。这些代理是从测试控制器获取有关测试内容的指令，并将请求发送到 SharePoint Server 2010 服务器场的计算机。测试结果本身存储在基于 SQL Server 的计算机上。不应使用用于 SharePoint Server 2010 服务器场的基于 SQL Server 的同一台计算机，因为在写入测试数据时，会影响 SharePoint Server 2010 服务器场的可用 SQL Server 资源的准确性。在运行测试时还需要监视测试服务器，就像监视 SharePoint Server 2010 服务器场中的服务器或域控制器等一样，从而确保测试结果代表您设置的服务器场。有时，负载代理或控制器本身会成为瓶颈。如果发生这种情况，则在测试中看到的吞吐量通常不是该服务器场可以支持的最大值。

  • SQL Server –在您的测试环境中，请遵循存储和 SQL Server 容量规划和配置 (SharePoint Server 2010) 一文中“配置 SQL Server”和“验证和监视存储和 SQL Server 性能”部分的指导。

  • 数据集验证 – 在确定您将要对其运行测试的内容后，请记住使用现有生产系统中的数据是最佳方案。例如，可以从生产服务器场备份内容数据库，并将其还原到测试环境，然后附加此数据库，以便将内容添加到服务器场。在对组成数据或示例数据运行测试时，可能会产生因内容集差异致使结果出现偏差的风险。

如果必须创建示例数据，则在构建该内容时要记住一些注意事项：

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

  • 导航应具现实性；不能超出用于生产的合理预期范围进行构建。

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

  • 确定您将需要的 SharePoint 组和/或权限级别的数量，以及将如何使其与用户关联。

  • 决定是否需要进行配置文件导入，以及该操作所需的时间。

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

  • 确定是否需要更多搜索内容资源，以及创建这些资源需要使用的内容。如果不需要创建它们，则确定是否具有能够对其进行爬网的网络访问权。

  • 确定是否有足够的示例数据（文档、列表、列表项等）。如果没有，则创建一个有关如何创建此类内容的计划。

  • 制订一个计划来获取足够的唯一内容，以便充分测试搜索。常见错误是将同一文档上载（可能上载数百次或数千次）到不同名称的不同文档库。这样会影响搜索性能，因为查询处理器会花费同样多的时间来执行重复检测，而在生产环境中使用实际内容时，则不必耗费这些时间。

创建测试和工具

在测试环境正常运行后，便可创建、微调用于测量服务器场性能容量的测试。本节有时会专门引用 Visual Studio Team System (Team Test Load Agent)，但不管使用哪种负载测试工具，许多概念都适用。有关 Visual Studio Team System 的详细信息，请参阅 MSDN 中的 Visual Studio Team System（该链接可能指向英文页面）(https://msdn.microsoft.com/zh-cn/library/fda2bad5.aspx" )。

还可以将 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 Administration Toolkit 1.0 版中，可从 Microsoft 下载中心（该链接可能指向英文页面） (https://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en)（该链接可能指向英文页面）下载它。

成功测试的重要条件是能够有效模拟实际工作量，方法是：在各种测试网站数据之间生成请求，就像用户访问生产 SharePoint Server 2010 服务器场中的各种内容一样。为此，通常需要构建测试，以使其成为数据驱动的测试。您应该只使用几项测试，这些测试使用的数据源包含可用于动态访问一组页面的项目的 URL，而不是创建数百个进行硬编码的用于访问特定页面的单独测试。

在 Visual Studio Team System (Team Test Load Agent) 中，数据源可以各种格式出现，但 CSV 文件格式通常最便于在开发和测试环境之间进行管理和传输。请记住，对该内容创建 CSV 文件可能需要创建自定义工具来枚举基于 SharePoint Server 2010 的环境，并记录正在使用的各种 URL。

您可能需要使用工具来执行相关任务，例如：

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

  • 枚举网站 URL、列表和库、列表项、文档等，并将其转换为用于负载测试的 CSV 文件

  • 上载各种文档库和网站中的示例文档

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

  • 创建“我的网站”

  • 使用用户名和密码创建供测试用户使用的 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 (Team Test Load Agent) 的属性，该属性可确定测试代理是应该尝试仅检索页面，还是应该尝试检索页面和属于该页面的所有关联请求，例如图像、样式表、脚本等。在进行负载测试时，我们通常忽略这些项目，原因如下：

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

    • 这些项目通常不是来自基于 SharePoint Server 2010 的环境中的 SQL Server。在启动 BLOB 缓存时，这些项目由 Web 服务器提供，因此不会产生 SQL Server 负载。

如果首次访问您的网站的用户比例通常都很高，或者您禁用了浏览器缓存，或者因故不能使用 BLOB 缓存，则在测试中启用分析相关请求可能很有意义。不过，这实际上是例外情况，而非适用于大多数实现的常规情况。请注意，如果确实要启用此功能，则会显著增加测试控制器报告的 RPS 数量。系统会迅速提供这些请求的服务，这样可能会使您误认为服务器场中包含超过实际容量的可用容量。

  • 还要记住为客户端应用程序活动建模。客户端应用程序（例如 Microsoft Word、PowerPoint、Excel 和 Outlook）也会向 SharePoint Server 2010 服务器场生成请求。通过发送服务器请求（例如检索 RSS 源）、获取社会信息、请求有关网站和列表结构的详细信息、同步数据等，这些请求会增加环境的负载。如果您的实现中包含这些客户端，则应该包括这些类型的请求并为其建模。

  • 在大多数情况下，Web 测试仅包含一个请求。如果测试中仅包含一个请求，则更易于微调测试工作和单独的请求，也更易于解决相应问题。如果 Web 测试正在模拟的操作由多个请求构成，则该测试通常需要包含多个请求。例如，若要测试这一组操作，则需要执行包含多个步骤的测试：签出文档，编辑文档，签入文档和发布文档。还需要保留各步骤之间的状态，例如，应使用同一用户帐户签出文档，编辑和签入该文档。对于需要在各个步骤之间转移状态的多步操作，最好通过在单个 Web 测试中包含多个请求来执行这些操作。

  • 单独测试各项 Web 测试。先确保每项测试能够成功完成，然后再在更大的负载测试中运行各个测试。确认已解析所有 Web 应用程序的名称，并且测试中使用的用户帐户有足够的权限执行测试。

Web 测试包含有关各个页面、上载文档、查看列表项的请求。所有这些测试均会汇总到负载测试中。您将在负载测试中插入将执行的所有不同 Web 测试。系统会为各项 Web 测试提供一定比例的执行时间，例如，如果您发现生产场服务器场中 10% 的请求是搜索查询请求，则表示在负载测试中，可将查询 Web 测试配置为运行 10% 的时间。在 Visual Studio Team System (Team Test Load Agent) 中，负载测试还包括如何配置浏览器组合、网络组合、负载模式和运行设置等事项。

对于负载测试，还有一些需要观察和实现的最佳做法：

  • 在测试中使用合理的读写比。测试中的写入次数过载会严重影响测试的整体吞吐量。在协作服务器场上，读写比甚至倾向于读取次数超过写入次数。有关详细信息，请参阅Performance and capacity technical case studies (SharePoint Server 2010)。

  • 考虑需要占用大量资源的其他操作的影响，并确定在负载测试期间是否执行这些操作。例如，在负载测试期间通常不执行备份和还原等操作。在负载测试期间，通常不会运行完整的搜索爬网，而是运行增量爬网。您需要考虑在生产中如何安排这些任务，是否在最大负载时间执行这些任务？如果不在最大负载时间执行，则可能在负载测试期间执行这些任务，在尝试确定最大稳定状态负载时，可以支持高峰流量。

  • 不使用思考时间。思考时间是 Visual Studio Team System (Team Test Load Agent) 的一项功能，利用该功能，您可以模拟用户在两次单击页面之间停顿的时间。例如，典型用户可能会加载页面，花三分钟阅读该页面，然后单击该页面上的链接以访问其他网站。如果要在测试环境中尝试模拟此操作，则几乎不可能准确完成，并且不能有效地将值添加到测试结果中。此操作很难模拟，因为大多数组织没有相关方法来监视不同用户以及用户在两次单击不同类型的 SharePoint 网站（如发布、搜索和协作等）之间花费的时间。此外，还无法添加值，因为即使用户可以在页面请求之间停顿，基于 SharePoint Server 2010 的服务器也不能在页面请求之间停顿。服务器只能获取稳定的请求流（其中可能包含一段时间内的高峰请求流和峡谷请求流），而不能在每个用户在两次单击页面上的链接之间停顿时闲置暂停。

  • 了解用户和请求之间的差别。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 2010 服务器场在最大负载期间可以维持的最大吞吐量，则选择恒定负载模式更有效、更准确。这样，您可以更轻松地确定系统可以承受多少负载，然后再开始定期超出正常运行的服务器场中应该保持的阈值。

每次运行负载测试时，请记住该过程会更改数据库中的数据。不管是在使用率数据库中上载文档、编辑列表项，还是记录活动，都会向 SQL Server 中写入数据。若要确保每个负载测试的测试结果集的一致性和合法性，请先进行备份，然后再运行第一项负载测试。在每项负载测试完成后，应使用备份将内容还原回开始测试之前所处的状态。

See Also

Concepts

SharePoint Server 2010 的容量管理和调整大小概述
SharePoint Server 2010 的容量规划
监控和维护 SharePoint Server 2010
运行状况监控 (SharePoint Server 2010)
存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)